`_environ` is meant to be DLL imported when linking against the C
runtime dynamically (`/MD` or `/MDd`). However, when building for
the Windows Runtime environment, we cannot support the use of `_environ`
and thus disable the support for that. `_WINRT_DLL` identifies the
combination of `/ZW` and `/LD` or `/LDd`. Windows Runtime builds cannot
be executables (and obviously not static libraries as they are not
executable), and thus we properly disable `ENVIRON` in all Windows
Runtime builds.
Fill out the metadata for Job to have a Dispatch-compatible vtable. When available, use the dispatch_enqueue_onto_queue_4Swift to enqueue Jobs directly onto queues. Otherwise, keep using dispatch_async_f as we have been.
rdar://75227953
Instead of doing the sanity checks by default (with an assert-build of the stdlib), only do the checks if the environment variable SWIFT_DEBUG_ENABLE_COW_SANITY_CHECKS is set to true.
The checks can give false alarms in case a binary is built against a no-assert stdlib but run with an assert-stdlib.
Therefore only do the checks if it's explicitly enabled at runtime.
rdar://problem/65475776
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.
