This will enable users to try out the '-enable-ossa-modules' flag if their
compiler supports it and get OSSA code on all inlinable code that they use. The
idea is that this is a nice way to stage this in and get more testing.
The specific implementation is that the module interface loader:
1. Knows if enable ossa modules is enabled not to search for any compiled
modules. We always rebuild from the interface file on the system.
2. Knows that if enable ossa modules is enabled to mixin a bit into the module
interface loader cache hash to ensure that we consider the specialized ossa
compiled modules to be different than the modules in that cache from the system.
This ensures that when said flag is enabled, the user transparently gets all
their code in OSSA form from transparent libraries.
Introduce a new compiler flag `-module-abi-name <name>` that uses the
given name as the ABI name for the module (rather than the module's
name in source code). The ABI name impacts name mangling and metadata.
Extend the checks for marker protocols and rethrows protocols to ensure
that we #if out more code that relies on them in module interface
generation. This makes the _Concurrency module parseable by much older
compilers.
Fixes rdar://75291705.
When a derived class does not inherit a designated initializer from
its base class, we override the designated initializer's vtable
entry with a stub which traps with a fatal error.
The stub cannot be called and clients do not need to be aware of
its existence, so don't print it at all in the module interface.
Fixes rdar://problem/71122015 / https://bugs.swift.org/browse/SR-13832.
Thanks to a great idea from Slava, simplify the printing of marker
protocols in Swift interfaces while maintaining backward compatibility.
For compilers that cannot handle marker protocols, print a typealias
to `Any` instead, which is a good stand-in for just about everything.
diag::warning_module_shadowing_may_break_module_interface was *enormous* but still described the problem too tersely to convey everything that was needed. Instead, reference a bug report that describes the problem and its workarounds in more detail.
There is a known issue with module interfaces where a type with the same name as a module will disrupt references to types in that module. Fully fixing it will require a new language feature (SR-898) which is not yet available. In the meantime, module interfaces support a workaround flag (“-Xfrontend -module-interface-preserve-types-as-written”) which prints an alternate form that usually works. However, you have to know to add this flag, and it’s not obvious because nothing breaks until a compiler tries to consume the affected module interface (or sometimes even one of its clients).
This commit emits a warning during module interface emission whenever the module interface either imports a type with the same name as the module being built, or declares a type with the same name as a visible module. This lets the user know that the type may cause problems and they might need to implement a workaround.
The check that limited inference of actor isolation meant that we were
incorrectly computing actor isolation for (e.g.) overrides when
parsing from Swift interfaces. Only limit inference for cases where we
are guaranteed to synthesize an attribute by inference.
This patch updates the `actor class` spelling to `actor` in almost all
of the tests. There are places where I verify that we sanely handle
`actor` as an attribute though. These include:
- test/decl/class/actor/basic.swift
- test/decl/protocol/special/Actor.swift
- test/SourceKit/CursorInfo/cursor_info_concurrency.swift
- test/attr/attr_objc_async.swift
- test/ModuleInterface/actor_protocol.swift
When generating a module interface, emit `#if` around any declarations
that are tied to specific, named language features. This allows module
interfaces to be processed by older Swift compilers that do not
support these newer features, such as async/await or actors.
The amount of effort required to correctly handle a new kind of
feature varies somewhat drastically based on the feature itself. The
"simple" case is where a particular declaration can only exist if a
feature is available. For example, and `async` declaration is fairly
easy to handle; a `@_marker` protocol's conformances are not.
Fixes rdar://73326633.
`InterfaceSubContextDelegateImpl` causes sub-instances to inherit `-fmodule-map-file=` options.
Those Module Maps become file dependencies of all downstream PCMs and their depending Swift modules, even though they really aren't.
This causes frequent re-builds of the Module Cache contents when seemingly-unrelated files are touched.
Explicit Module Builds rely on these options for building Swift Interface files, so for now we just disable inheritance of these options in Implicit Module builds.
The error shown when the compiler fails to build a module from its
textual interface has been creating some confusion. This is a proposal
to make it more useful to the programmer not working in the SDK, insist
on looking at the previous errors first, put less emphasis on possible
compiler bugs, and always show alternatives to the incompatible
compilers issue as this is the most common case now.
Availability macros passed via the frontend flag -define-availability
should be accepted by @_originallyDefinedIn where they behave as they do
in @available.
rdar://72354787
swift-driver passes down an SDK version number with a non-existing build number as 0.
The compiler should be resilient to this so we can locate prebuilt module cache.
rdar://72230172
Protocol requirements declared as a function with a result-builder
custom attribute should keep that attribute in the generated textual
swiftinterface file.
rdar://72063255
Passing the frontend flag -Rmodule-loading makes the compiler emit
remarks with the path of every module loaded. The path for Swift modules
is either the swiftinterface file for modules built with library
evolution or the binary swiftmodule otherwise. The path for clangmodules
is always in the cache which could be improved as it may be less useful.
Here's an extract of the output for a simple SwiftUI app:
<unknown>:0: remark: loaded module from
/Users/xymus/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/2VJP7CNCGWRF0/SwiftShims-18ZF6992O9H75.pcm
<unknown>:0: remark: loaded module from
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.2.sdk/usr/lib/swift/Swift.swiftmodule/x86_64-apple-ios-simulator.swiftinterface
<unknown>:0: remark: loaded module from
/Users/xymus/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/2VJP7CNCGWRF0/os-1HVC6DNXVU37C.pcm
<unknown>:0: remark: loaded module from
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.2.sdk/usr/lib/swift/os.swiftmodule/x86_64-apple-ios-simulator.swiftinterface
<unknown>:0: remark: loaded module from
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.2.sdk/System/Library/Frameworks/SwiftUI.framework/Modules/SwiftUI.swiftmodule/x86_64-apple-ios-simulator.swiftinterface
