This removes the C++ interop compat version mechanism. It was added in mid-2023 and was never used. It complicates the testing story, and makes it harder to reason about the compiler's behavior. It also isn't compatible with explicit module builds.
The flag `-cxx-interoperability-mode` is preserved, so projects that use the flag will continue to build normally.
rdar://165919353
This adds the -Rmacro-expansions flag. It provides similar functionality
to -dump-macro-expansions, but instead of dumping the macro expansion to
stderr, it emits it line by line as remarks. This is useful for testing
with -verify, where both macro expansion content and warnings need to be
tested at the same time.
For clients, such as the debugger, who do not have access the full
output of the dependency scanner, it is a huger performance and
correctness improvement if each explicitly built Swift module not just
serialized all its Clang .pcm dependencies (via the serialized Clang
compiler invocation) but also its direct Swift module dependencies.
This patch changes the Swift module format to store the absolute path
or cas cache key for each dependency in the INPUT block, and makes
sure the deserialization makes these available to the ESML.
rdar://150969755
We have long switched to delegate the checking of whether a module is up-to-date to the build system (SwiftDriver) and stopped serializing file dependencies for interface-built binary modules.
Resolves rdar://162881032
_SwiftifyImport assumes types like Swift.Int, Swift.UnsafePointer<T> and
Swift.Span<T> are available. This is not the case when building the
stdlib itself. Disable safe interop in the stdlib to prevent errors.
This currently has no effect, but will when this feature is enabled by
default, which I have manually tested.
Add support for the `Swift` availability domain, which represents availability
with respect to the Swift runtime. Use of this domain is restricted by the
experimental feature `SwiftRuntimeAvailability`.
With some changes that I am making, we will no longer need this flag at the SIL
level, so we can just make it an IRGen flag (which it really should have been
in the first place).
The flags "-import-bridging-header" and "-import-pch" import a bridging
header, treating the contents as a public import. Introduce
"internal-" variants of both flags that provide the same semantics,
but are intended to treat the imported contents as if they came in
through an internal import. This is just plumbing of the options for
the moment.
This flag dumps all imports for each SourceFile after it's gone through
import resolution. It is only intended for testing purposes.
There are other ways to print imports, but they don't correspond 1:1 to
the imports actually resolved, which is a bit problematic when testing
implicit clang module imports.
The definitions of how version numbers were extracted from target
triples split between the minimum platform version and for determining
the minimum inlining version.
This resulted in inlinable and transparent functions not being imported
correctly on non-Apple platforms where the version number is retained as
part of the target triple.
Specifically, `_checkExpectedExecutor` was found in the module, but
didn't have the appropriate availability version assigned, resulting in
it failing to import and the compiler silently omitting the check in
SILGen when compiling for FreeBSD.
This patch refactors the implementation of `getMinPlatformVersion` into
a separate function that is used in both places so that they cannot get
out of sync again.
Note: This changes how Windows is handled. getMinPlatformVersion
returned an empty version number for Windows, while the availability
implementation returned the OS version number. This makes both
consistently return the OS version number.
Set an upper bound on the number of chained lookups we attempt to
avoid spinning while trying to recursively apply the same dynamic
member lookup to itself.
rdar://157288911
Let's set the limits to high end of what we'd expect to prevent regressions.
These still require some profiling to fine-tune but the original limits are
far too small for SwiftUI views we see in pactice.
Resolves: rdar://156896778
Controlled from Swift with '-version-independent-apinotes', which, for the underlying Clang invocation enables '-fswift-version-independent-apinotes', results in PCMs which aggregate all versioned APINotes wrapped in a 'SwiftVersionedAttr', with the intent to have the client pick and apply only those that match its current Swift version, discarding the rest.
This change introduces the configuration flags for this mode as well as the corresponding logic at the beginning of `importDeclImpl` to canonicalize versioned attributes, i.e. select the appropriate attributes for the current target and discard the rest.
We sometimes don't have the information in the modulemaps whether a
module requires ObjC or not. This info is useful for reverse interop.
This PR introduces a frontend flag to have a comma separated list of
modules that we should import as if they had "requires ObjC" in their
modulemaps.
Most of the logic for C++ foreign reference types can be applied to C types as well. Swift had a compiler flag `-Xfrontend -experimental-c-foreign-reference-types` for awhile now which enables foreign reference types without having to enable C++ interop. This change makes it the default behavior.
Since we don't expect anyone to pass `experimental-c-foreign-reference-types` currently, this also removes the frontend flag.
rdar://150308819
The concrete nesting limit, which defaults to 30, catches
things like A == G<A>. However, with something like
A == (A, A), you end up with an exponential problem size
before you hit the limit.
Add two new limits.
The first is the total size of the concrete type, counting
all leaves, which defaults to 4000. It can be set with the
-requirement-machine-max-concrete-size= frontend flag.
The second avoids an assertion in addTypeDifference() which
can be hit if a certain counter overflows before any other
limit is breached. This also defaults to 4000 and can be set
with the -requirement-machine-max-type-differences= frontend flag.
When building against the static standard library, we should define
`SWIFT_STATIC_STDLIB` to indicate to the shims that the declarations
should be giving hidden visibility and default DLL storage. This is
required to ensure that these symbols are known to be `dso_local` when
compiling to avoid an unnecessary look up through the PLT/GOT or the
indirection through the synthesized `__imp_` symbol and the IAT. This
corrects a number of incorrect code generation cases on Windows with the
static standard library.
Textual interfaces for 'Darwin' built with recent compilers specify that it is built witout C++ interop enabled. However, to ensure compatibility with versions of the 'Darwin' module built with older compilers, we hard-code this fact. This is required to break the module cycle that occurs when building the 'Darwin' module with C++ interop enabled, where the underlying 'Darwin' clang module depends on C++ standard library for which the compiler brings in the 'CxxStdlib' Swift overlay, which depends on 'Darwin'.
The migration to `MemberImportVisibility` can be performed mechanically by
adding missing import declarations, so offer automatic migration for the
feature.
Resolves rdar://151931597.
This feature is essentially self-migrating, but fit it into the
migration flow by marking it as migratable, adding
`-strict-memory-safety:migrate`, and introducing a test.
