Introduce a new behavior when printing references to modules with an
`export_as` definition. Use the `export_as` name in the public swiftinterface
and the real module name in the private swiftinterface.
This has some limits but should still be an improvement over the current
behavior. First, the we use the `export_as` names only for references to clang
decls, not Swift decls with an underlying module defining an `export_as`.
Second, we always print the `export_as` name in the public swiftinterface,
even in the original swiftinterface file when the `export_as` target is likely
not know, so that generated swiftinterface is still broken.
This behavior is enabled by the flags `-enable-experimental-feature ModuleInterfaceExportAs`
or the `SWIFT_DEBUG_USE_EXPORTED_MODULE_NAME_IN_PUBLIC_ONLY` env var. We may
consider turning it on by default in the future.
rdar://98532918
Macros are an experimental feature, as such are not available on
non-asserts compilers.
Adding requires asserts to remaining experimental macro tests.
- ModuleInterface/macros.swift
- Serialization/macros.swift
This new flag should allow module authors to specify allowable client list. This list is printed
in the textual module interface. Diagnostics support can come later.
In AliasModuleNames, avoid wrongfully printing aliased names for modules
that were not aliased. This can happen in the case of modules indirectly
imported via a reexport.
rdar://102262019
https://github.com/apple/swift/pull/42041 introduced a centralized mechanism for adding the `nonisolated` attribute to synthesized decls but did not clean up the existing code that was already doing so for `Hashable` conformances.
Resolves rdar://102106591
Ambiguities are introduced in generated swiftinterfaces when a type
shares a name with a module (i.e. XCTest). This workaround uses the
module-alias feature to avoid these ambiguities. Writing module
references with a distinguishable prefix should allow normal
type-checking to avoid the usual ambiguities.
We should still aim for a proper fully-qualified named syntax, but this
may help in the mean time.
rdar://101969500
This flag restricts availability of certain symbols to ensure the code cannot use declarations that are explicitly unavalable to extensions. This restriction should be passed down to dependency modules also.
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.
