We need to be able to locate `swift-backtrace` relative to the current
location of the runtime library.
This needs to work:
* In a Swift build directory.
* On Darwin, where we're installed in /usr/lib/swift and /usr/libexec/swift.
* On Linux, where we're in /usr/lib/swift/linux and /usr/libexec/swift/linux.
* On Windows, where we may be in a flat directory layout (because of limitations
of Windows DLL lookups).
rdar://103071801
The test was inadvertently depending on the ordering of output between
stderr and stdout, which makes it break particularly when being run
remotely.
rdar://88335113
Previously, when NDEBUG was not defined, the allocations made for value
metadata records were filled with 0xAA bytes. Here, that behavior is
both expanded to all metadata records and enabled in release builds when
the environment variable SWIFT_DEBUG_ENABLE_MALLOC_SCRIBBLE is set.
In #32137 direct environment variable parsing was introduced, the
availability of which is branched by a preprocessor symbol (`ENVIRON`)
if the environment is available directly on the platform, or if getenv
must be used.
The message expectation in the unit test in the however diverged on the
non-`ENVIRON` branch, causing a unit test failure. This PR fixes the
expectation, but also, while we're here, OpenBSD supports the `ENVIRON`
branch anyway.
There are a few environment variables used to enable debugging options in the
runtime, and we'll likely add more over time. These are implemented with
scattered getenv() calls at the point of use. This is inefficient, as most/all
OSes have to do a linear scan of the environment for each call. It's also not
discoverable, since the only way to find these variables is to inspect the
source.
This commit places all of these variables in a central location.
stdlib/public/runtime/EnvironmentVariables.def defines all of the debug
variables including their name, type, default value, and a help string. On OSes
which make an `environ` array available, the entire array is scanned in a single
pass the first time any debug variable is requested. By quickly rejecting
variables that do not start with `SWIFT_`, we optimize for the common case where
no debug variables are set. We also have a fallback to repeated `getenv()` calls
when a full scan is not possible.
Setting `SWIFT_HELP=YES` will print out all available debug variables along with
a brief description of what they do.
