Having package-name printed in public or private interface led to strange dependency errors in the past. For example, an SPI module is a dependency within a package, but due to the package-name being printed in public or private interface, dependency scanner tries to find it even for an external client of the package, causing a `no such module found` error. The -disable-print-package-name-for-non-package flag helps with such case, but to enforce the correct behavior, we should make it a default to not print package-name in public or private interface.
Resolves rdar://135260270
Replace the existing C++ implementation of extractInlinableText with
a new implementation based on swift-syntax. It uses SwiftIfConfig to
remove inactive regions (with a special mode), and a new compiler-only
entrypoint in the library to remove comments and `#sourceLocation`.
This warning is designed to be an early report of name conflicts in
swiftinterfaces caused by a type having the same name as a module.
Make sure we silence this warning when the workaround
-alias-module-names-in-module-interface is enabled. This is what we
already do for -module-interface-preserve-types-as-written.
rdar://132990400
The reverse-condfail workaround needs to be removed, and this is the
first step to allowing the stdlib to build with conditionally escapable
types.
resolves rdar://132453000
With `-experimental-lazy-typecheck` specified during module interface emission,
`collectProtocols()` may be the first piece of code to request the extended
type for a given extension and it therefore needs to ignore invalid extensions
and ensure that diagnostics are emitted.
Also, add some `PrettyStackTrace` coverage to `ModuleInterfaceSupport.cpp` to make
investigating future issues easier.
Resolves rdar://126232836.
This is necessary to ensure that availability checks contained in inlined
functions are compiled correctly for zippered modules when built from
interface.
Resolves rdar://130094532.
Using init accessors from inlinable code requires `@usableFromInline`
annotation, which means that we need to print them in swift interfaces
and serialize them.
Although actor initializers can be classified as convenience initializers by
the internals of the compiler, they are not written that way in source and
should not be printed with the `convenience` keyword.
Resolves rdar://130926278.
Since these features are experimental features, they can't be catagorized as
"baseline" features. However, there is no need to guard code in swiftinterfaces
that potentially uses syntax related to these features since all supported
compilers can parse the syntax.
It is no longer necessary to produce `.swiftinterface` files the support older
compilers that lack support for the NoncopyableGenerics feature. Cleaning this
up makes the stdlib `.swiftinterface` far more readable.
The `convenience` keyword is not accepted on actor initializers because the
compiler infers this status automatically and actors cannot be subclassed.
However, internally the compiler still computes whether an actor init is a
convenience init and this implicit status has been leaking through accidentally
in printed `.swiftinterface` files. This was noticed because in Swift 6 the
presence of the keyword is diagnosed as an error, making `.swiftinterface`
files unparseable for modules containing actors with convenience inits.
For Swift 6, I'm just going to suppress the error in `.swiftinterface` files
regardless of language mode. In future releases of the compiler, though, it can
stop printing the `convenience` keyword on these inits altogether, though.
Resolves rdar://130857256.
