64-bit Windows defines both _WIN64 and _WIN32, so the logic here would
always end up defining 32-bit C types for Swift's `Int` and `UInt`.
Fix the ordering to check for 64-bit first, then 32-bit second.
Note that the SwiftShims version of this code has always been wrong,
but it's completely benign because SwiftShims is only used in the
Swift runtime itself, which is built with Clang (on all platforms),
and doesn't need to go through this code path. Still, we fix it in both
places, so we don't get a nasty surprise if the SwiftShims version of
the header later gets included in a non-Clang C++ compiler.
The C type tha corresponds to Swift's pointer-sized `Int` and `UInt`
types varies from one platform to the next. The canonical C types are
`ptrdiff_t` and `size_t`, but we're in the depths of the compiler we
can't include the C library headers that provide them because they
introduce cyclic module dependencies. Sigh.
SwiftShims has some logic to compute these types. However, SwiftShims
is part of the Swift runtime, not the compiler, so those headers
cannot be included here. So, we clone the logic and simplify it
somewhat for our use case.
This fixes truncation issues on Windows, where the uses of
`unsigned long` and `long` for Swift(U)Int are incorrect.
These allow multi-statement `if`/`switch` expression
branches that can produce a value at the end by
saying `then <expr>`. This is gated behind
`-enable-experimental-feature ThenStatements`
pending evolution discussion.
This enables one to use varying prefixes when checking diagnostics with the
DiagnosticVerifier. So for instance, I can make a test work both with and
without send-non-sendable enabled by adding additional prefixes. As an example:
```swift
// RUN: %target-swift-frontend ... -verify-additional-prefix no-sns-
// RUN: %target-swift-frontend ... -verify-additional-prefix sns-
let x = ... // expected-error {{This is always checked no matter what prefixes I added}}
let y = ... // expected-no-sns-error {{This is only checked if send non sendable is disabled}}
let z = ... // expected-sns-error {{This is only checked if send non sendable is enabled}}
let w = ... // expected-no-sns-error {{This is checked for a specific error when sns is disabled...}}
// expected-sns-error @-1 {{and for a different error when sns is enabled}}
```
rdar://114643840
The generic `char_traits` implementation was deprecated and has since
been removed from libc++ (https://reviews.llvm.org/D157058). When
building with a libc++ that has it removed, the `basic_string<T>`
overloads cause errors during template substitution.
Macro implementations can come from various locations associated with
different search paths. Add a frontend flag `-Rmacro-loading` to emit
a remark when each macro implementation module is resolved, providing
the kind of macro (shared library, executable, shared library loaded
via the plugin server) and appropriate paths. This allows one to tell
from the build load which macros are used.
Addresses rdar://110780311.
The scudo runtime was renamed to indicate that it now must run
standalone from other sanitizers. This patch updates the driver to
search for the appropriate filename.
LLVM rename: https://reviews.llvm.org/D138157
When `-warn-on-potentially-unavailable-enum-case` was introduced, the build
system was required to invoke `swift-frontend` at artificially low deployment
targets when emitting `.swiftinterface` files for legacy architectures. Because
the deployment target was low, some availability diagnostics needed to be
de-fanged in order to allow module interface emission to succeed. Today, the
build system is able to use the correct deployment target when emitting module
interfaces and the `-warn-on-potentially-unavailable-enum-case` is superfluous,
so deprecate it.
Resolves rdar://114092047
Clang dependency scanning produces scanner PCMs which we may want to live in a
different filesystem location than the main build module cache.
Resolves rdar://113222853
In C++20, `u8` literals create values of type `char8_t` instead of
`char`, and these can't be implicitly converted. This macro
mitigates the difference and allows the same code to compile under
C++14/17 modes and C++20, preserving the `char` type while ensuring
that the text is interpreted as UTF-8.
