"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
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
This path was not exercised in the test suite, and when the
PrimaryAssociatedTypes feature finally (incorrectly) triggered it,
it would print '#endifextension'.
and make `@_unsafeInheritExecutor` a suppressible feature.
Some language features are required in order to parse a
declaration correctly, but some can safely be ignored.
For the latter, we'd like the module interface to simply
contain the declaration twice, once with the feature and
once without. Some basic support for that was already
added for the SpecializeAttributeWithAvailability feature,
but it didn't interact correctly with required features
that might be checked in the same `#if` clause (it simply
introduced an `#else`), and it wasn't really set up to
allow multiple features to be handled this way. There
were also a few other places that weren't updated to
handle this, presumably because they never coincided
with a `@_specialize` attribute.
Introduce the concept of a suppressible feature, which
is anything that the ASTPrinter can modify the current
PrintOptions in order to suppress. Restructure the
printing of compatibility checks so that we can print
the body multiple times with different settings.
Print required feature checks in an outer `#if...#endif`,
then perform a separate `#if...#else...#endif` within
if we have suppressible features. If there are multiple
suppressible features, check for the most recent first,
on the assumption that it will imply the rest; then
perform subsequent checks with an `#elsif` clause.
This should be a far more solid foundation on which to
build compatibility checks in the future.
`@_unsafeInheritExecutor` needs to be suppressible
because it's been added to some rather important
existing APIs. Simply suppressing the entire decl will
effectively block old tools from using a new SDK to
build many existing projects (if they've adopted
`async`). Dropping the attribute changes the semantics
of these functions, but only if the compiler features
the SE-0338 scheduling change; this is a very narrow
window of main-branch development builds of the tools,
none of which were officially released.
It's been quite a long time since this unused parameter was introduced.
The intent is to produce the module as a root for the search - that is,
computing the set of conformances visible from that module, not the set
of conformances inside of that module. Callers have since been providing
all manner of module-scoped contexts to it.
Let's just get rid of it. When we want to teach protocol conformance
lookup to do this, we can revert this commit as a starting point and try
again.
Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
Don't print indirect conformances for protocols that are
implementation-only imported. Indirect conformances are synthesized when
the middle protocol is internal and not printed in the swiftinterface.
This logic didn't previously check for implementation-only imports,
likely because type-checking usually forbids it. Let's still protect
this use case as we are considering relaxing this type-checking
restriction in the future.
rdar://78718838
The patch introduces a new setting instead of changing existing settings
because the generated interfaces in the IDE have slightly different
requirements; the extended type there is unconditionally not printed
qualified (even if it is ambiguous). This is likely because the
ambiguity heuristic is very weak; it doesn't even do name lookup.
Simplifying that logic would be nice, but then we'd need to update
a bunch of IDE/print* tests and end up with more more visual clutter
in the IDE.
Introducing the new setting means we can change the behavior for
swiftinterface files without affecting the behavior for IDE interfaces.
Fixes rdar://79093752.
Titled as "// swift-module-flags-ignorable:", this new field contains new
frontend arguments that can be safely ignored by the older version of the compiler.
For compilers that don't know the field at all, all arguments in it are ignored.
rdar://78233352
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.
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.
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.
Clang types need special treatment because multiple Clang modules can contain the same type declarations from a textually included header, but not all of these modules may be visible.
This fixes
https://bugs.swift.org/browse/SR-13032
The newly added test breaks without this fix.
To help consolidate our various types describing imports, this commit moves the following types and methods to Import.h:
* ImplicitImports
* ImplicitStdlibKind
* ImplicitImportInfo
* ModuleDecl::ImportedModule
* ModuleDecl::OrderImportedModules (as ImportedModule::Order)
* ModuleDecl::removeDuplicateImports() (as ImportedModule::removeDuplicates())
* SourceFile::ImportFlags
* SourceFile::ImportOptions
* SourceFile::ImportedModuleDesc
This commit is large and intentionally kept mechanical—nothing interesting to see here.
The lack of clarity manifested as unexpected behavior when using
getImportedModules to create the module import graph. The new behavior
makes SPI-ness and Shadowing-ness behave similarly in terms of
filtering. We also check if a filter is well-formed to avoid
accidental empty import lists.
Dummy conformances are generated when a conditional conformance is
constrained by a type that is not to be printed. In case the types
involved are SPI, mark the dummy conformance SPI in the private
swiftinterface only.
Print implementation-only imports in the private textual interface
only if also importing SPI. This allows to export types from
implementation-only imports in SPI and brings the private textual
interfaces in line with the binary interfaces.
This is a temporary solution as we need to better design the language
feature around this.
This feature requires passing -experimental-spi-imports to the frontend
that generates the private swiftinterface file.
This makes it easier to specify OptionSet arguments.
Also modify appropriate uses of ModuleDecl::ImportFilter to take
advantage of the new constructor.
Using a SetVector fixes an issue where many source files imported the
same SPI group from the same module, the emitted private textual
interfaces superfluously repeated the `@_spi` attribute on the import.
rdar://problem/63681845
This simplifies fixing the master-next build. Upstream LLVM already
has a copy of this function, so on master-next we only need to delete
the Swift copy, reducing the potential for merge conflicts.
