Replaces `ComponentIdentTypeRepr::getIdentifier()` and `getIdLoc()` with `getNameRef()` and `getNameLoc()`, which use `DeclName` and `DeclNameRef` respectively.
When SE-110 was being implemented, we accidentally began to accept
closure parameter declarations that had no associated parameter names,
e.g.
foo { ([Int]) in /**/ }
This syntax has never been sanctioned by any version of Swift and should
be banned. However, the change was made long enough ago and there are
enough clients relying on this, that we cannot accept the source break
at the moment. For now, add a bit to ParamDecl that marks a parameter
as destructured, and back out setting the invalid bit on the type repr
for these kinds of declarations.
To prevent further spread of this syntax, stub in a warning that offers
to insert an anonymous parameter.
Resolves part of rdar://56673657 and improves QoI for errors like
rdar://56911630
Fixed compiler crasher 28651 now exits in milliseconds rather than seconds
because the constraint solver is no longer trying to solve a large
number of nested closures with missing right braces.
Use the isInvalid() bit on the TypeRepr to signal that a closure
parameter is potentially a tuple destructure. This has two benefits
1) Parse is no longer using the isInvalid() bit on Decl
2) Invalidating the type repr itself means that we no longer spuriously
diagnose variable patterns in destructures as missing types.
TypeCheckPattern used to splat the interface type into this, and
different parts of the compiler would check one or the other. There is
now one source of truth: The interface type. The type repr is now just
a signal that the user has written an explicit type annotation on
a parameter. For variables, we will eventually be able to just grab
this information from the parent pattern.
Since getSpecifier() now kicks off a request instead of always
returning what was previously set, we can't pass a ParamSpecifier
to the ParamDecl constructor anymore. Instead, callers either
call setSpecifier() if the ParamDecl is synthesized, or they
rely on the request, which can compute the specifier in three
specific cases:
- Ordinary parsed parameters get their specifier from the TypeRepr.
- The 'self' parameter's specifier is based on the self access kind.
- Accessor parameters are either the 'newValue' parameter of a
setter, or a cloned subscript parameter.
For closure parameters with inferred types, we still end up
calling setSpecifier() twice, once to set the initial defalut
value and a second time when applying the solution in the
case that we inferred an 'inout' specifier. In practice this
should not be a big problem because expression type checking
walks the AST in a pre-determined order anyway.
This simplifies the code and prevents an assertion failure this code was
hitting computing the type relations between the result types and what it
determined as the expected type.
Resolves rdar://problem/53958454
So that we can easily detect 'ParsedSyntaxNode' leaking. When it's
moved, the original node become "null" node. In the destructor of
'ParsedSyntaxNode', assert the node is not "recorded" node.
InterpolatedStringLiteralExpr has a TapExpr, which contains a BraceStmt
containing the builder CallExprs to the builder appendInterpolation /
appendStringLiteral methods used to construct the final string. This is all
implementation detail, but the BraceStmt wasn't marked implicit and had a valid
(but incorrect) SourceRange, so the document structure request treated it as
any other BraceStmt and made a structure node for it. The invalid range ended
up tripping an assertion in the document structure walker in swift-ide-test.
This patch corrects the BraceStmts produced by interpolated strings to be
marked implicit and have the correct range, and also updates ModelASTWalker to
skip over the internal details of interpolated strings when walking them (the
CallExprs were also being emitted).
