For now the semantics provided by `@extensible` keyword on per-enum
basis. We might return this as an upcoming feature in the future with
a way to opt-out.
This attribute controls whether cross-module access to the declaration
needs `@unknown default:` because it's allowed to gain new cases even
if the module is non-resilient.
We implement getIdentitySubstitutionMap() by passing in
a no-op substitution callback. Remove the unnecessary
getCanonicalType() call, to ensure that the abstract
conformance in the identity substitution map uses the
sugared form of the subject type.
Introduce a convenience for aborting while printing a given message
to a frame of the pretty stack trace. Use this in the existing places
where we're currently doing this.
While here, fix some issues around implied isolated conformances (we
could get into an inconsistent state). Also provide an educational
note discussing isolated conformances and the kinds of errors one can
see when they are used from outside of their isolation domain.
The changes in https://github.com/swiftlang/swift/pull/80040 caused the
compiler to start diagnosing extensions containing only members that are
either `@_spi`, `@_alwaysEmitIntoClient`, or unavailable when the
`-require-explicit-availability` flag is passed. Extensions should not be
diagnosed when they only contain members that would not be diagnosed
themselves.
Resolves rdar://148275432.
The earlier changes to ASTDumper only printed information like
retroactiveness and safety when printing the `InheritedEntries`
of a decl. Now that we print the actual resolved semantic
information instead of the inheritance list as-written, we need
to surface these values via the `ProtocolConformance`s.
When a generic function has potentially Escapable outputs, those outputs
declare lifetime dependencies, which have no effect when substitution
leads to those types becoming `Escapable` in a concrete context.
This means that type substitution should canonically eliminate lifetime
dependencies targeting Escapable parameters or returns, and that
type checking should allow a function value with potentially-Escapable
lifetime dependencies to bind to a function type without those dependencies
when the target of the dependencies is Escapable.
Fixes rdar://147533059.
- For type USRs, use `mapTypeOutOfContext()` to replace primary
archetypes with type parameters. If the type contains local
archetypes, replace them with their existential upper bounds.
- For inheritance of types, print the derived semantic information
instead of the inheritance list as it is written.
- Dump conformance requirements as protocol decl USRs instead of
type USRs, since the latter involves an existential conversion
that loses suppressed protocols.
- Fix a small bug in conformance dumping where the `MemberLoading`
field wasn't propagated to the nested printer, which caused
protocols to be dumped as simple names instead of USRs.
Rather than fixing-up in the parser, adjust the ASTScope logic such
that a `try` element in a SequenceExpr is considered as covering all
elements to the right of it. Cases where this isn't true are invalid,
and will be diagnosed during sequence folding. e.g:
```
0 * try foo() + bar()
_ = try foo() ~~~ bar() // Assuming `~~~` has lower precedence than `=`
```
This ensures we correctly handle `try` in assignment sequences, and
allows ASTGen to get the behavior for free.
rdar://132872235
This issue manifested in crashing when in Xcode one would do the Archive
workflow, and we would be missing the Distributed module types and
proceed to run into a nullpointer when faced with code like this:
```
public class TestViewModel {
public init() {}
public func onReturn() {
print("on return executed!")
}
}
```
where the name matched one of the ad hoc requirements, but we'd get null
for the protocol lookup since this does not import the distributed
module.
resolves rdar://148327936
Suppose module 'Foo' exists in the search paths and specifies user module version '1.0'.
If the first encountered 'canImport' query is unversioned:
...
Followed by a versioned one:
...
The success of the first check will record an unversioned successful canImport, which will cause the second check to evaluate to 'true', which is incorrect.
This change causes even unversioned 'canImport' checks to track and record the discovered user module version.
