The release job has been dependent on sign-and-package-windows and
sign-and-package-mac, each of which depends on build. But that indirect
dependency doesn't convey access to ${{ needs.build.outputs.xxx }}. Add the
build job to direct dependencies so release can access its outputs.
With GitHub viewer builds, every few weeks we've seen test failures when
ll_frand() returns exactly 1.0. This is a problem for a function that's
supposed to return [0.0 .. 1.0).
Monty suggests that the problem is likely to be conversion of F32 to F64 to
pass to fmod(), and then truncation of fmod()'s F64 result back to F32. Moved
the clamping code to each size-specific ll_internal_random specialization.
Monty also noted that a stateful static random number engine isn't
thread-safe. Added a mutex lock.
The test was coded to push (what's intended to be) the third entry with
timestamp (now + 200ms), then (what's intended to be) the second entry with
timestamp (now + 100ms).
The trouble is that it was re-querying "now" each time. On a slow CI host, the
clock might have advanced by more than 100ms between the first push and the
second -- meaning that the second push would actually have a _later_
timestamp, and thus, even with the queue sorting properly, fail the test's
order validation.
Capture the timestamp once, then add both time deltas to the same time point
to get the relative order right regardless of elapsed real time.
clang has gotten smart enough to recognize an inline attempt to store to
address zero. Fool it by storing to an address passed as a parameter, and pass
nullptr from a different source file.
Even though LLVersionInfo::getBuild() already returns a 64-bit int, various
consumers assumed it could fit into 32 bits. It was especially bad to pass it
to a classic C style varargs function. Only on a little-endian CPU, and only
because it was the last argument, the damage was limited to truncation --
instead of arbitrary undefined behavior.
Where the consumer doesn't support 64-bit ints, pass as string instead.
The header file documents that no llrand function should ever return a value
equal to the passed extent, so the one test in llrand_test.cpp that checked
less than or equal to the high end of the range was anomalous.
But changing that to an exclusive range means that we no longer need separate
exclusive range and inclusive range functions. Replace
ensure_in_range_using(), ensure_in_exc_range() and ensure_in_inc_range() with
a grand unified (simplified) ensure_in_range() function.
This reverts commit edf0874e06.
Reverted since it causes a significant uptick in shutdown freezes.
Can't repro those freezes, will seek an alternate solution.
glext, which contains only header files, now builds only a single common
package instead of platform-specific ones. But as long as we retain the
platform-specific URLs, autobuild will continue to prefer those over the
common platform. Remove all platform-specific glext package entries.
It's frustrating and unactionable to have a failing test report merely that
the random value was greater than the specified high end. Okay, so what was
the value? If it's supposed to be less than the high end, did it happen to be
equal? Or was it garbage? We can't reproduce the failure by rerunning!
The new ensure_in_exc_range(), ensure_in_inc_range() mechanism is somewhat
complex because exactly one test allows equality with the high end of the
expected range, where the rest mandate that the function return less than the
high end. If that's a bug in the test -- if every llrand function is supposed
to return less than the high end -- then we could simplify the test logic.
This branch cleans up crufty code in build.yaml, build.sh and
viewer_manifest.py that was packaging, signing and uploading installers before
the SL-19242 work.
Nat Goodspeed