Diagnose situations where a sub-class or a protocol do not have all
of the reflection metadata attributes required by a superclass.
Resolves: rdar://103990788
This ensures that when we're printing multiple module interfaces, we separate out
the namespaces and their members correctly between the produced module interfaces.
- SILPackType carries whether the elements are stored directly
in the pack, which we're not currently using in the lowering,
but it's probably something we'll want in the final ABI.
Having this also makes it clear that we're doing the right
thing with substitution and element lowering. I also toyed
with making this a scalar type, which made it necessary in
various places, although eventually I pulled back to the
design where we always use packs as addresses.
- Pack boundaries are a core ABI concept, so the lowering has
to wrap parameter pack expansions up as packs. There are huge
unimplemented holes here where the abstraction pattern will
need to tell us how many elements to gather into the pack,
but a naive approach is good enough to get things off the
ground.
- Pack conventions are related to the existing parameter and
result conventions, but they're different on enough grounds
that they deserve to be separated.
A lot of existing regression tests rely on there
being some form of move-only classes, despite
them being something that will not be available
to users (and not complete).
This change introduces a `MoveOnlyClasses`
experimental feature so that those tests don't
need to be fully rewritten just yet. You need to
include `-enable-experimental-feature MoveOnlyClasses` along with
`-enable-experimental-move-only` to get move-only classes.
Since type wrapper attributes could be applied to protocols and
the protocol types could be used as existential values, it's not
always possible to wrap all uses of feature into `#if $TypeWrappers`
block so let's allow use of attributes if they come from a Swift
interface file.
Align the grammar of macro declarations with SE-0382, so that macro
definitions are parsed as an expression. External macro definitions
are referenced via a referenced to the macro `#externalMacro`. Define
that macro in the standard library, and recognize uses of it as the
definition of other macros to use externally-defined macros. For
example, this means that the "stringify" macro used in a lot of
examples is now defined as something like this:
@expression macro stringify<T>(_ value: T) -> (T, String) =
#externalMacro(module: "MyMacros", type: "StringifyMacro")
We still parse the old "A.B" syntax for two reasons. First, it's
helpful to anyone who has existing code using the prior syntax, so they
get a warning + Fix-It to rewrite to the new syntax. Second, we use it
to define builtin macros like `externalMacro` itself, which looks like this:
@expression
public macro externalMacro<T>(module: String, type: String) -> T =
Builtin.ExternalMacro
This uses the same virtual `Builtin` module as other library builtins,
and we can expand it to handle other builtin macro implementations
(such as #line) over time.
Introduce the experimental feature `ParserDiagnostics`, which emits
diagnostics from the new Swift parser *first* for a source file. If
that produces any errors, we suppress any diagnostics emitted from the
C++ parser.
`usesFeatureTypeWrappers` should return `true` for all of
the declarations that use the feature directly or indirectly
e.g. type wrapper types, type wrapped types, and types with
conformance to a type wrapped protocol (with or without wrapper
attribute inference).
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
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
