In #86859, I modified the way `export_as` names are used in private module interfaces so that the `export_as` name is used when that module has been imported. This turns out to be slightly too aggressive in a specific scenario where a submodule of the export_as module imports a submodule of the real module—the compiler ends up using the export name even though the resulting lookup won’t actually work.
Modify the logic for deciding whether to use an exported module name so that it not only checks whether the export_as module has been loaded, but also whether the specific module or submodule the declaration belongs to is (possibly transitively) imported by that module.
Fixes rdar://167874630 (harder).
Modify relevant portions of the type-checker and parser to allow, when the 'LiteralExpressions' experimental feature is enabled, for arbitrary integer-typed expressions in enum raw value specifiers. These expressions will be type-checked and constant-folded into an integer literal expression, keeping the current interface of 'EnumElementDecl' consistent for clients.
Previously, 'EnumRawValuesRequest' had two different "modes" which were discerned based on typechecking stage (structural | interface), where the former had the request compute all raw values, both user-specified literal expressions and computing increment-derived values as well; the latter would also type-check the user-specified expressions and compute their types.
- With the need to have enum case raw values support arbitrary integer expressions, the request ('EnumRawValuesRequest') has been refactored and simplified to *always* both compute all case raw values and perform type-checking of user-specified raw value expressions. This is done in order to allow the AST-based constant-folding infrastructure ('ConstantFoldExpression' request) to run on the expressions. Constant folding is invoked during the evaluation of 'EnumRawValuesRequest' on all user-specified raw value expressions, in order to be able to compute subsequent increment values and ensure the expressions are foldable. If they are not, i.e. if constant folding fails, a relevant diagnostic will be emitted.
- 'EnumElementDecl' continues to store the raw value expression, which is no longer a 'LiteralExpr' but rather an 'Expr'; however, the getter ('getRawValueExpr') continues to return a 'LiteralExpr' by invoking the constant-folding request on the stored value, which is guaranteed to return a cached result from a prior invocation in 'EnumRawValuesRequest', assuming it succeeded.
- Furthermore, the 'structural' request kind was previously not cached, whereas now because the request must always do the complete type-checking work, it is always cached.
Resolves rdar://168005520
Given that we implicitly expanded Copyable & Escapable
conformance requirements for suppressed primary associated
types, we now need this function to do the opposite;
filtering Copyable & Escapable requirements on such primary
associated types and adding inverses if those requirements
are missing.
This function plays a crucial role in emitting the interface
files accurately for functions and types, in addition to
how we mangle generic signatures into function symbols.
The mangling for generic signatures under the -WithDefaults version of
suppressed associated types goes like this:
- primary associated type T.A has an inverse `Rj` or `RJ` mangled
into the generic signature if it lacks the conformance, or
nothing is mangled into it.
- non-primary associated type T.B has either a `T.B: Copyable`
requirement mangled into it, or nothing is mangled into it.
For the legacy SuppressedAssociatedTypes feature, where there's no
defaults, it uses the "non-primary assocated type" mangling strategy
for all generic signatures.
We may visit and thus import these members in an unpredictable order.
To avoid future churn for module interface test cases, sort the printed
module interface output according to some rough heuristics.
The `@reparented` was missing and a typealias
was being synthesized unexpectedly, creating
an issue when typechecking the interface later.
There's no fundamental reason why typealiases
cannot be supported to say the same thing as
the same-type requirement, but I think the
same-type requirement is always needed to be
written on the extension, one way or another.
For now I've chosen to only go with an
explicitly-written same-type requirement.
We fall back to indices when labels are not available, but labels are
preferable, because they readable, stable, and preferred by the lifetime
dependencies proposal.
Previously, if a declaration belonged to a module with an `export_as` attribute, Swift always used the exported module name in the public module interface and the real module name in the private module interface. However, this is only a rough approximation of the behavior we really want, which is to use the real name in module interfaces that might be imported by dependencies of the exported name.
Change this logic so that public interfaces always use the exported name, and private interfaces use the exported name *only* if a module with that name has been loaded. This should make it so that if you’re building the `export_as` module or anything that imports it, you use the exported name; otherwise you use the real name.
Fixes rdar://167874630.
Don't look through sugar when checking whether to print
`nonisolated(nonsending)` in parameter positions, because
underlying types would already be marked appropriately
and parameters themselves doesn't require the modifier
transfer even when the sugar is stripped.
Resolves: rdar://167050741
This updates a large number of internal symbols, function names,
and types to match the final approved terminology. Matching the
surface language terminology and the compiler internals should
make the code easier for people to understand into the future.
There were a number of cases where Swift would emit module selectors into module interface files that it was subsequently unable to parse because the compiler at least temporarily represented them as dependent member types. Modify the carve-out so that if *any* of a type’s parents are generic parameters or archetypes, we don’t print a module selector on it.
Fixes rdar://166180424.
The type of an outermost property wrapper should be printed together
with (inferred) generic arguments because otherwise if a any wrapper
in the chain has generic parameters that are not involved in
`wrappedValue:` argument it won't be impossible to infer them while
type-checking the interface file where it appears.
Resolves: rdar://122963120
When emitting module interfaces, parameterized protocols in inheritance clauses were being printed with generic arguments (public struct T: Fancy<Float64>), causing errors with protocol conformance verification.
The fix strip ParameterizedProtocolType to its base protocol type when printing inherited types, producing the correct inheritance clause.
Resolves: rdar://161925627
We currently disallow these by deleting them in the `swift` namespace.
This approach has several loopholes, all of which ultimately work
because we happen to define specializations of `simplify_type` for
`swift::Type`:
* `llvm::isa/cast/dyn_cast`. The deleted partial specializations will
not be selected because they are not defined in the `llvm` namespace.
* The argument is a non-const `Type`. The deleted function templates
will not be selected because they all accept a `const Type &`, and
there is a better `Y &Val` partial specialization in LLVM.
* Other casting function templates such as `isa_and_nonull` and
`cast_if_present` are not deleted.
Eliminate these loopholes by instead triggering a static assertion
failure with a helpful message upon instantiation of `CastInfo` for
`swift::Type`.
Printing shouldn't rely on parameter declaration bit because it only
works in cases when there is an explicit `nonisolated(nonsending)`
modifier on the type.
Always print `nonisolated(nonsending)` before `sending`, `@escaping`
and other declaration attributes/modifiers to avoid parsing issues.
Resolves: rdar://164267736
With the feature enabled any function type without an explicit `@concurrent`
is going to be inferred to be `nonisolated(nonsending)`. `@concurrent` should
always be printed for diagnostic and other purposes because the isolation
checking would consider them to be `nonisolated(nonsending)` otherwise, especially
important to code produced by fix-its.
Resolves: rdar://161739470
This was always set to `true` except for USR mangling, where we already
have it set to `false` for IDE USRs. The other clients were:
- AutoDiff, which is just using the resulting string as a dictionary
key, so don't seem to have any preference.
- The ClangImporter, which always overrides `@_originallyDefinedIn`
anyway.
.swiftinterface sometimes prints a pattern binding initializer and the
accessor block. However the parser doesn't expect such constructs and
the disambiguation from trailing closures would be fragile. To make it
reliable, introduce a disambiguation marker `@_accessorBlock` .
`ASTPrinter` prints it right after `{` only if 1) The accessor block is
for a pattern binding declaration, 2) the decl has an initializer
printed, and 3) the non-observer accessor block is being printed. In the
parser, if the block after an initializer starts with
`{ @_accessorBlock`, it's always parsed as an accessor block instead of
a trailing closure.
rdar://140943107
This is currently not wired up to anything. I am going to wire it up in
subsequent commits.
The reason why we are introducing this new Builtin type is to represent that we
are going to start stealing bits from the protocol witness table pointer of the
Optional<any Actor> that this type is bitwise compatible with. The type will
ensure that this value is only used in places where we know that it will be
properly masked out giving us certainty that this value will not be used in any
manner without it first being bit cleared and transformed back to Optional<any
Actor>.
Becca Royal-Gordon
Artem Chikin
Kavon Farvardin
John Hui
Aidan Hall
Aidan Hall
Meghana Gupta
Xi Ge
Sam Pyankov
Joe Groff
elsa
Erik Eckstein
Elsa Keirouz
Tim Kientzle
Pavel Yaskevich
Pavel Yaskevich
Doug Gregor
Anthony Latsis
Slava Pestov
Hamish Knight
Rintaro Ishizaki
Michael Gottesman