It's very, very easy to make a mistake that will cause broken
serialized modules. Until that's no longer true, at least tell folks
that they are heading into uncharted waters, as we do with
`@_implementationOnly` imports.
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 command-line option hasn't been Objective-C specific ever, really.
Make the language-independent spelling the primary one to make that
more obvious.
These restrictions will generally manifest as failures of various forms
later in the compiler process. Enable the diagnostics to give earlier
feedback to help stay within the bounds of Embedded Swift.
Fixes rdar://121205043.
swift_coroFrameAlloc was introduced in the Swift 6.2 runtime. Give it
the appropriate availability in IRGen, so that it gets weak
availability when needed (per the deployment target). Then, only
create the stub function for calling into swift_coroFrameAlloc or
malloc (when the former isn't available) when we're back-deploying to
a runtime prior to Swift 6.2. This is a small code size/performance
win when allocating coroutine frames on Swift 6.2-or-newer platforms.
This has a side effect of fixing a bug in Embedded Swift, where the
swift_coroFrameAlloc was getting unconditionally set to have weak
external linkage despite behind defined in the same LLVM module
(because it comes from the standard library).
Fixes rdar://149695139 / issue #80947.
If a .swiftinterface file does not include an explicit `-language-mode` option
(or its predecessor `-swift-version`) and needs to be built as a dependency of a
client compilation, then the invocation to build the module from interface
would end up inheriting the language mode that the client code is built with.
This can result in spurious type checking diagnostics or even mis-compilation.
To ensure that a module interface is always built using the language mode that
its source code was originally built with, require an explicit `-language-mode`
option when emitting swiftinterface files.
In https://github.com/swiftlang/swift/pull/84307 this diagnostic was downgraded
to a warning. The failures it caused in PR testing should now be resolved.
Resolves rdar://145168219.
Downgrade the new error in https://github.com/swiftlang/swift/pull/84244 to a
warning.
The PR smoke test build is using a different build system that is failing to
pass `-swift-version` arguments when building various stdlib modules. That
needs to be fixed, but for now we also need to unblock CI.
If a `.swiftinterface` file does not include an explicit `-language-mode`
option (or its predecessor `swift-version`) and needs to be built as a
dependency of a client compilation, then the invocation to build the module
from interface would end up inheriting the language mode that the client code
is built with. This can result in spurious type checking diagnostics or even
mis-compilation. To ensure that a module interface is always built using the
language mode that its source code was originally built with, require an
explicit `-language-mode` option when emitting swiftinterface files.
Resolves rdar://145168219.
Currently, swift-frontend will always try to infer a default CASPath if
no `-cas-path` is passed. The function `getDefaultOnDiskCASPath` called
to infer the default path can fatal error in some environment where no
caching directory and home directory, no matter if caching is used or
not.
Remove the inferred path during parsing since that is not strictly
necessary. If caching is enabled and no CASPath is passed, error can be
issued during CAS construction time.
rdar://158899187
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
Given an explicitly-nonisolated type such as
nonisolated struct S { }
all extensions of S were also being treated as nonisolated. This meant
that being implicitly nonisolated (i.e., when you're using nonisolated
default isolation) was different from explicitly-writing nonisolated,
which is unfortunate and confusing. Align the rules, such that an
extension of S will get default isolation:
extension S {
func f() { } // @MainActor if we're in main actor default isolation
}
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.
Previously this flag was only used to pass explicit dependencies to compilation tasks. This change adds support for the dependency scanner to also consider these inputs when resolving dependencies.
Resolves https://github.com/swiftlang/swift-driver/issues/1951
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.
Since LayoutPrespecialization has been enabled by default in all compiler
invocations for quite some time, it doesn't make sense for it to be treated as
experimental feature. Make it a baseline feature and remove all the
checks for it from the compiler.
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
