Printing the name will help in the case of xrefs for an extension member
and more. This will create errors messages like this in the case of a
module with an extension not being loaded:
```
x. *** DESERIALIZATION FAILURE ***
module 'SomeModule' with full misc version ...
module with extension is not loaded (MyExtensionModule)
Cross-reference to module 'TypesOriginalModule'
... TypeBeingExtended
```
rdar://91316948
We were building the signature twice, and adding the 'where' clause twice
each time.
The GSB magically uniqued them, whereas the Requirement Machine is not
so forgiving.
This ensures that opened archetypes always inherit any outer generic parameters from the context in which they reside. This matters because class bounds may bind generic parameters from these outer contexts, and without the outer context you can wind up with ill-formed generic environments like
<τ_0_0, where τ_0_0 : C<T>, τ_0_0 : P>
Where T is otherwise unbound because there is no entry for it among the generic parameters of the environment's associated generic signature.
We now schedule conformance emissions in basically the same way
we do for types and declarations, which means that we'll emit them
uniquely in the module file instead of redundantly at every use.
This should produce substantially smaller module files overall,
especially for modules that heavily use generics. It also means
that we can remove all the unfortunate code to support using
different abbrev codes for them in different bitcode blocks.
Requirement lists are now emitted inline in the records that need
them instead of as trailing records. I think this will improve
space usage, but mostly it assists in eliminating the problem
where abbrev codes are shared between blocks.
The RequirementSignature generalizes the old ArrayRef<Requirement>
which stores the minimal requirements that a conforming type's
witnesses must satisfy, to also record the protocol typealiases
defined in the protocol.
Clang importer diagnostics that are produced as a result of a reference
in Swift code are attached to as notes to the Sema produced diagnostic
that indicates the declaration is unavailable.
Ex: Notes about why a C function import failed are attached to
the error explaining that the symbol could not be found in scope.
In addition to the predefined cases, like "readnone", "readonly", etc. support providing a custom string, which will be parsed later.
Also, allow multiple effects attributes to be put onto a function.
The `@exclusivity(unchecked)` attribute can be used on variables to selectively disable exclusivity checking.
For completeness, also the `@exclusivity(checked)` variant is supported: it turns on exclusivity checking for specific variables if exclusivity enforcement is disabled by the command line option.
This new attribute is a missing implementation part of SE-0176 (https://github.com/apple/swift-evolution/blob/main/proposals/0176-enforce-exclusive-access-to-memory.md).
rdar://31121356
Opened archetypes can be created in the constraint system, and the
existential type it wraps can contain type variables. This can happen
when the existential type is inferred through a typealias inside a
generic type, and a member reference whose base is the opened existential
gets bound before binding the generic arguments of the parent type.
However, simplifying opened archetypes to replace type variables is
not yet supported, which leads to type variables escaping the constraint
system. We can support cases where the underlying existential type doesn't
depend on the type variables by canonicalizing it when opening the
existential. Cases where the underlying type requires resolved generic
arguments are still unsupported for now.
Nested archetypes are represented by their base archetype kinds (primary,
opened, or opaque type) with an interface type that is a nested type,
as represented by a DependentMemberType. This provides a more uniform
representation of archetypes throughout the frontend.
Form opened archetype types based on an interface type and existential
type, rather than assuming all OpenedArchetypeType instances only
represent the root. Sink the UUID, existential type, and actual creation
of the opened archetype into the opened generic environment, so we
consistently only create new archetype instances from the generic
environment. This slims down OpenedArchetypeType and makes it work
similarly to the other archetype kinds, as well as generalizing it
to support nested types.
Sink the existential type and UUID of an
As another step toward eliminating NestedArchetypeType, generalize the
representation, construction, and serialization of primary and sequence
archetypes to interface types, rather than generic parameter types.
The first generic parameter of an `OpaqueTypeDecl` was still being used
as the "underlying" interface type of the opaque type, which is
incorrect for both structural and named opaque result types. Eliminate
this notion, because the (declared) interface type already has the
correct structure.
Only ABI checking depended on the old "underlying" type, so rework it to
instead substitute into properly for structural opaque result types as
well.
Deserialization required a small adjustment to eliminate a cycle
because the interface type of an `OpaqueTypeDecl` involves opaque
archetype types, which reference the declaration itself... so
deserialize the interface type later, now that it's correct.
This patch introduces new diagnostics to the ClangImporter to help
explain why certain C, Objective-C or C++ declarations fail to import
into Swift. This patch includes new diagnostics for the following entities:
- C functions
- C struct fields
- Macros
- Objective-C properties
- Objective-C methods
In particular, notes are attached to indicate when any of the above
entities fail to import as a result of refering an incomplete (only
forward declared) type.
The new diangostics are hidden behind two new flags, -enable-experimental-clang-importer-diagnostics
and -enable-experimental-eager-clang-module-diagnostics. The first flag emits diagnostics lazily,
while the second eagerly imports all declarations visible from loaded Clang modules. The first
flag is intended for day to day swiftc use, the second for module linting or debugging the importer.
Generalize the implementation of opaque type declarations to maintain
the "ordinal", which represents a particular "some" utterance in a
structural opaque type, throughout more of the compiler.
The ordinal value for a given "some" matches with the index of the
corresponding generic parameter in the opaque type declaration's
generic signature. To properly be able to determine the ordinal for a
given "some" type representation, retain all of the "some" type
representations in the `OpaqueTypeDecl` (using trailing storage), so
we can map them to the proper generic parameter and ordinal later on.
The new type, called ExistentialType, is not yet used in type resolution.
Later, existential types written with `any` will resolve to this type, and
bare protocol names will resolve to this type depending on context.
Adding the ability to add an optional message to the unavailable from
async attribute. This can be used to indicate other possible API to use,
or help explain why it's unavailable.
This attribute creates an unavailable extension with a `Sendable` conformance so that the type is explicity marked as not being `Sendable`.
We also fully suppress diagnostics about unavailable Sendable conformances in Swift 5 mode code. (This is not fully developed yet—it should return to being a warning in concurrent contexts.)
The behavior when a @_nonSendable and a Sendable conformance are both on the same type is also not right yet.
