For Swift 3 / 4:
Deprecate the spelling "ImplicitlyUnwrappedOptional", emitting a warning
and suggesting "!" in places where they are allowed according to
SE-0054.
In places where SE-0054 disallowed IUOs but we continued to accept them
in previous compilers, emit a warning suggesting "Optional" or "?" as
an alternative depending on context and treat the IUO as an Optional,
noting this in the diagnostic.
For Swift 5:
Treat "ImplicitlyUnwrappedOptional" as an error, suggesting
"!" in places where they are allowed by SE-0054.
In places where SE-0054 disallowed IUOs, emit an error suggestion
"Optional" or "?" as an alternative depending on context.
We can't construct a nominal type with an ErrorType as a
parent, so in the bad circular case, return a Type() instead
to bail out of transform() altogether.
This commit also adds ArrayExpr and DictionaryExpr to the libSyntax nodes
family. Also, it refactors the original parser code for these two
expressions to better fit to the design of SyntaxParsingContext.
This commit has also fixed two crashers.
Previously, we were inferring requirements from types within the definitions
of protocols, e.g., given something like:
protocol P {
associatedtype A: Collection
associatedtype B where A.Element == Set<B>
}
we would infer that B: Hashable. The code for doing this was actually
incorrect due to its mis-use of requirement sources, causing a few
crashers. Plus, it's not a good idea in general because it hides the
actual requirements on B. Stop doing this.
Also stop trying to infer requirements from conditional
requirements---those have already been canonicalized and minimized, so
there's nothing to infer from.
If we encounter a superclass or concrete source within a conformance
access path, use the stored conformance to terminate the path. Fixes a
compiler crasher.
Fixes a former crasher that included well-formed code that was rejected
by my previous refactoring. Said crasher now passes, and IRGen's properly
as well. Also, account for three more fixed crashers.
Use the "override" information in associated type declarations to provide
AST-level access to the associated type "anchor", i.e., the canonical
associated type that will be used in generic signatures, mangling,
etc.
In the Generic Signature Builder, only build potential archetypes for
associated types that are anchors, which reduces the number of
potential archetypes we build when type-checking the standard library
by 14% and type-checking time for the standard library by 16%.
There's a minor regression here in some generic signatures that were
accidentally getting (correct) same-type constraints. There were
existing bugs in this area already (Huon found some of them), while
will be addressed as a follow-up.
Fies SR-5726, where we were failing to type-check due to missed
associated type constraints.
The various _*Indexable protocols only exist to work around the lack of
recursive protocol constraints. Eliminate all of the *_Indexable protocols,
collapsing their requirements into the corresponding Collection protocol
(e.g., _MutableIndexable —> Collection).
This introduces a number of extraneous requirements into the various
Collection protocols to work around bugs in associated type
inference. Specifically, to work around the lack of "global" inference
of associated type witnesses. These hacks were implicitly present in
the *Indexable protocols; I've made marked them as ABI FIXMEs here so
we can remove them when associated type inference improves.
Fixes rdar://problem/21935030 and a number of ABI FIXMEs in the library.
Once we compute a generic signature from a generic signature builder,
all queries involving that generic signature will go through a separate
(canonicalized) builder, and the original builder can no longer be used.
The canonicalization process then creates a new, effectively identical
generic signature builder. How silly.
Once we’ve computed the signature of a generic signature builder, “register”
it with the ASTContext, allowing us to move the existing generic signature
builder into place as the canonical generic signature builder. The builder
requires minimal patching but is otherwise fully usable.
Thanks to Slava Pestov for the idea!
The type checker shouldn’t know about potential archetypes. Use
GenericSignatureBuilder::resolveEquivalenceClass() and perform the lookup
into that instead.
The test case change highlights an existing problem with generic signature
minimization.
Once we compute a generic signature from a generic signature builder,
all queries involving that generic signature will go through a separate
(canonicalized) builder, and the original builder can no longer be used.
The canonicalization process then creates a new, effectively identical
generic signature builder. How silly.
Once we’ve computed the signature of a generic signature builder, “register”
it with the ASTContext, allowing us to move the existing generic signature
builder into place as the canonical generic signature builder. The builder
requires minimal patching but is otherwise fully usable.
Thanks to Slava Pestov for the idea!
We allowed them for generic parameter inheritance clauses but
not anywhere else. While arguably this has stylistic benefits,
the restriction was not enforced consistently and was mostly a
result of implementation limitations.
Lift the restriction and fix things up where needed to make them
work. This brings us closer to allowing protocols to constrain
the 'Self' type to a subclass of a class by listing the class in
the protocol's inheritance clause, which was a feature from SE-0156,
but this doesn't quite work.
Fixes <https://bugs.swift.org/browse/SR-4678> and
<rdar://problem/31785092>.
When resolving protocol composition types, using the
old type checker to resolve the type manually instead
of the iterative type checker submits a recursive-but-
satisfiable request to the ITC. This way we directly
resolve through TypeCheckType and can catch the
circularity before it takes down the compiler.
Now that we remember the DeclContext of lookup results when
doing unqualified lookup, we don't have to walk parent contexts
again to find this DeclContext.
This means that unqualified lookup is now the "single source of
truth" for what names are visible and why.
There are two "RAII cleaners" here:
- CleanupIllFormedExpressionRAII cleans up the Expr in its final state
- ExprCleanser walks the Expr before it is mutated and collects
sub-expressions, then cleans those up after
The subtle difference comes into play if we started to apply the
solution (which can fail, leaving the AST in an inconsistent state)
or if preCheckExpression() modified the AST.
The latter case was causing an ASan failure because we were not
cleaning up type variables in new nodes introduced by
preCheckExpression().
Fix this by moving the preCheckExpression() call out of
solveForExpression(), so that if solveForExpression() is called
with TypeCheckExprFlags::SkipApplyingSolution, we don't mutate the
AST at all.
Sigh...
Fixes <rdar://problem/33277279>.
When a type variable binds to an (unresolved) dependent member type,
it prevents us from inferring the type variable and adds no useful
information to the system. Refuse to bind type variables to dependent
member types.
Fixes rdar://problem/32697033.
If we encounter an associated type reference within a concrete type, but
haven't seen a specific protocol requirement, add the protocol
conformance.
Fixes rdar://problem/33139928 and another crasher.
We don't need to force the creation of potential archetypes when
finding anchors, because new potential archetypes will only be created
by this process in ill-formed generic signatures. Tolerate failure
whenever this happens (for now) and the failure paths will become dead
once AlwaysPartial is eliminated fully.
In some circumstances, we could end up growing increasingly-nested
potential archetypes due to a poor choice of representatives and
anchors. Address this in two places:
* Always prefer to use the potential archetype with a lower nesting
depth (== number of nested types) to one with a greater nesting
depth, so we don't accumulate more nested types onto the
already-longer potential archetypes, and
* Prefer archetype anchors with a lower nesting depth *except* that we
always prefer archetype anchors comprised of a sequence of
associated types (i.e., no concrete type declarations), which is
important for canonicalization.
Fixes SR-4757 / rdar://problem/31912838, as well as a regression
involving infinitely-recursive potential archetypes caused by the
previous commit.
