We use functions from Shell32.Lib. Ensure that we indicate the
autolinking to the linker. This aides when building with a static
runtime to avoid having to specify the additional library dependency for
clients that are attempting to link against the runtime. This is
particularly important for the CMake compiler check where we would need
to list Shell32 as a required link library.
We should always be using `<errno.h>`, not `<sys/errno.h>`. The
former is part of the C standard. The latter is a non-standard
header that happens to be present on some systems.
rdar://123507361
In `/proc/self/maps`, the stack isn't necessarily a single range, even
immediately after process start-up. Apparently sometimes it's possible
for the kernel to allocate extra ranges below the first one, and these
show up separately in `/proc/self/maps`.
The upshot was that we were finding that `environ` didn't point into
the stack range we found, and then returning no arguments as a result.
The fix is to merge contiguous ranges after the first stack range we
find in `/proc/self/maps`.
rdar://117963394
Instead of reading from `/proc/self/cmdline`, take advantage of the fact
that the initial stack layout is ABI specified, and that we already have
a pointer into it (`environ`). This lets us walk up the stack until we
find `argc`, at which point we also know where `argv` is.
We do this from a static initializer because a `setenv()` or `putenv()`
can change `environ` (if you add a new environment variable), and it's
even permissible to just outright change `environ` yourself too. It
seems reasonable to suggest to people that they shouldn't be doing
those things from a static initializer, and as long as they don't,
they won't run before we've had a chance to find `argv`.
Just in case someone _does_ do this, we also check that `environ`
points into the stack. If it doesn't, they won't get any arguments,
so if that happens, that's a clue that they're messing with `environ`
too early.
This works around a problem (#69658) with Docker Desktop 4.25.0 and
Rosetta, wherein we end up with an extra argument visible in
`/proc/self/cmdline`, and also avoids allocating memory for the
command line arguments.
rdar://117963394
`SWIFT_RUNTIME_STDLIB_INTERNAL` does `extern "C"`, so we can't put these
in a namespace and have to use a C-style prefix instead.
Also slightly rearrange the code in `CommandLine.cpp`.
rdar://103397975
Instead of triggering a fatal error on failure, return `nullptr` and
let the caller decide what to do about it. The CommandLine code should
trigger a fatal error, of course.
rdar://103397975
In various places we need to call the Windows API, and because Swift uses UTF-8
for its string representation, we can’t call the ANSI API functions (because the
code page used for the ANSI functions varies depending on the system locale
setting). Instead, we need to use the wide character APIs.
This means that we need to convert UTF-8 to wide character and vice-versa in
various places in the runtime.
rdar://103397975
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
This is for the 'freestanding' build to stop assuming the platform has argc/argv.
- Introduce a new sub-library, libswiftCommandLineSupport.a
- Move stubs/CommandLine.cpp into this library
- Conditionally embed it into libswiftCore
- Conditionally embed it into libswiftPrivateLibcExtras if not in libswiftCore to support testing
- Add SWIFT_STDLIB_HAS_COMMANDLINE CMake (and build-script) flag
