Global actors have been an accepted language feature for a couple of compiler releases now, but the feature definition was associated with the `--enable-experimental-concurrency` flag. This caused some `.swiftinterface`s containing global actor declarations to be unparsable because the logic for surrounding declarations with the `$GlobalActors` feature guard was incomplete (for example, classes with a global actor attribute were not guarded even though the declarations of global actor types were).
Rather than trying to fix the logic of `usesFeatureGlobalActors()`, enable it by default.
Adds a test that demonstrates that modules defining and using public global actors produce module interfaces that can be parsed successfully.
Resolves rdar://100150703
"Extra" protocols from a superclass are already handled when printing the superclass, so we should not accumulate them when recording protocols for a subclass.
Resolves rdar://98523784
This attribute will, in the near future, be used to inform IRGen that a nominal type that conforms to such protocol must have its type metadata always emitted into the binary, regardless of whether it is used/public.
This test establishes a baseline for the behavior of swiftinterface emission when public declarations of all kinds reference typealiases from another module. It seems that for many types of declarations, the printer is looking through the typealias definition and printing the original type instead of a fully qualified reference to the typealias. This behavior can cause swiftinterfaces to be unparsable since the original type may not be declared in the module declaring the typealias.
Every CHECK line in this test that includes a reference to fully qualified type from the `Original` module represents an instance of this bug.
Once this behavior is corrected, it should be possible to succesfully parse `UsesAliases.swiftinterface` and the `RUN:` line for doing so should be uncommented.
Prebuilt modules are only available for certain toolchain and SDK combinations. Therefore,
building modules from interface, even for the stdlib, is expected to happen.
related: rdar://96701615
`@_nonSendable` types get a synthesized, unavailable extension that
declares the Sendable conformance. This extension also needs to have
appropriate platform availability for the type that is being marked
non-Sendable, so the platform-specific attributes are copied from the
nominal type declaration. However, for nested types, we might need to
copy those attributes from an enclosing declarations. Do so when
appropriate.
Fixes rdar://90330588.
If a function's parameter or return types involve nominal types that
have been moved across modules using @_originallyDefinedIn, we must
take care to always mangle the opaque result type's name using the
original module names and not the current module names.
This was a problem with DWARF mangling, which normally disables
@_originallyDefinedIn for other purposes. Make sure to always
temporarily re-enable it when mangling an opaque result type.
Fixes rdar://problem/93822207.
Erroneous declaration attributes were sometimes being printed in the private swiftinterfaces of modules because the changes from https://github.com/apple/swift/pull/42276 were effectively corrupting the attribute list for any decl with sythesized conformances (e.g. `Equatable`, `Hashable`). It is necessary to clone the attributes before adding them to the synthesized conformance extension decls.
Resolves rdar://94009296
lit.py currently allows any substring of `target_triple` to be used as a
feature in REQUIRES/UNSUPPORTED/XFAIL. This results in various forms of
the OS spread across the tests and is also somewhat confusing since they
aren't actually listed in the available features.
Modify all OS-related features to use the `OS=` version that Swift adds
instead. We can later remove `config.target_triple` so that these don't
the non-OS versions don't work in the first place.
If we have an internal function with a `_specialize` attribute that has
a `targetFunction:` parameter we want the function to appear in the
.swiftinterface file such that the exported specialization can be picked up by
the compiler.
Always use the swiftinterfaces of modules under the public Frameworks
folder in the SDK. Distributed swiftmodules are unreliable, they should
only be used as a local cache. Let's avoid them when possible.
rdar://92037292
- Tests that depend on emitted interfaces should generally use flags that are typical for modules that have textual interfaces (e.g. `-enable-library-evolution`).
- If a test is intended to produce a valid `swiftinterface` then it should verify that interface. This will help prevent interface printing regressions caused by compiler changes.
- Having commonly used substitutions for tests that emit interfaces makes it easy to experiment with compiler flags that might effect interface printing.
Resolves rdar://91634358
