Recent Swift uses 2 as the is-Swift bit when running on newer versions, and 1 on older versions. Since it's difficult or impossible to know what we'll be running on at build time, make the selection at runtime.
Instead of capturing SubstGenericParametersFromMetadata and SubstGenericParametersFromWrittenArgs by value, capture by reference.
This avoids those instances to be copied and thus avoids a lot of mallocs.
SR-10028
rdar://problem/48575729
This dramatically reduces the number of needed malloc calls.
Unfortunately I had to add the implementation of SmallVectorBase::grow_pod to the runtime, as we don't link LLVM. This is a bad hack, but better than re-inventing a new SmallVector implementation.
SR-10028
rdar://problem/48575729
We would not previously symbolicate the stack trace and as a result
would not display the stack trace. Add symbolication support to the
runtime to actually make use of the captured stack trace. This allows
us to get a stack trace when the standard library or swift code reports
a fatal error.
Because Microsoft inlines the definitions of the printf family of
functions, we end up with undefined references to them. Add an explicit
request to link against the `legacy_stdio_definitions` library when
`ucrt.C.stdio` is used which provides out-of-line definitions for them.
This fixes the building of the `stdlib/VarArgs' test.
Windows uses `char *` for the `va_list` type even on x86_64. Restore
the correct selection of `__VaListBuilder` for Windows x86_64. This
partially fixes variadic functions.
These are supposed to be processed in the C locale always, irrespective
of the current locale. We were not doing this and so we would parse the
value incorrectly.
Windows uses carriage returns and newlines. The string matching is
sensitive to this. Simply erase carriage returns from the standard
error stream to compensate.
Update the shims logic to make sure that it works for Xcode as well.
Rather than adding additional rules, just simplify it down to the one
canonical way in modern LLVM land. The headers are always installed to
the LLVM_LIBRARY_OUTPUT_INTDIR which will be defined for us in both the
standalone and unified build mode. This allows us to just remove all
the work to find the headers since they will always be in one location.
We've been collecting the location info for some time now, but
apparently never printed it in no-assert builds of the stdlib, which
means this functionality was never available to the users.
With this change, the location will be printed depending on the
debug/release build configuration of the program, not stdlib.
Somewhat addresses: <rdar://problem/42980523>
The assertions here are based around the idea that `std::atomic` is
trivially constructible which is not a guarantee that the standard fully
provides. The default initialization of the `std::atomic` type may
leave it in an undetermined state. These were caught using the Visual
C++ preview runtime.
Ideally, the object constructor would use a placement new operator.
However, prior to C++17, the C++ standard mandated that there be a
NULL pointer check in the placement new operator. This is something
which is no longer the case with C++17. Switch to the placement new
operator for C++17 and newer and enable that codepath for Windows as
well (which seemingly elides the null-pointer check with clang-cl).
When compiling for a 32 bit machine, uintptr_t from ReflectionInfo will
be the integer sized to hold a 32 bit pointer, so a 64 bit pointer might
not fit.
This commit removes the solution in
0f20c486e0 and does a runtime check that
the calculated offset will fit into the target machine uintptr_t, which
might not be true for 32 bits machines trying to read 64 bits images,
which should not be that common (and those images have to have offsets
bigger than what a 32 bits number can hold).
Rather than directly using the extension `__builtin_expect`, use a macro
to permit the removal of the builtin on compilers which do not support
this (i.e. cl). This permits us to build the swift compiler with MSVC
again.
- Add an underscore to private/internal symbols
- Make access levels explicit, even when they’re implied from context
- Conform to max line length of 80 characters
- Conformances declared on separate extensions that implement them
- Arrange member declarations so that stored properties appear first
- Expand single-letter function and type parameter names where there is an obvious name that’s more descriptive
- RangeReplaceableCollection.fastApplicationEnumeration → CollectionDifference._fastEnumeratedApply
We were previously treating all the builds as shared, which is not the
case for the host library build of SwiftRemoteMirror. The warnings were
lost in the interminable spew from the build which is now fixed and this
stands out.
`-Wall` with the clang-cl interface gives us `-Weverything` effectively,
which really reduces the effectiveness of the warnings. Switch to `/W3`
which is roughly equivalent to `-Wall` in clang mode.
