parseClosureSignatureIfPresent.
Otherwise, closure parameters that were parsed as "potentially destructured"
will fail constraint generation, even after the parser has decided
they are not destructured.
* Stage in #filePath
To give users of #file time to transition, we are first adding #filePath without changing #file’s behavior. This commit makes that change.
Fixes <rdar://problem/58586626>.
* Correct swiftinterface test line
If we are code-completion, we need to keep the parsed expression in the
AST. Don't discard the parsed expression if the middle expression in a
ternary expression has code-completion token. This improves the
completions for:
let _: MyEnum = condition ? .<HERE>
let _: MyEnum = condition ? .<HERE> :
rdar://problem/54132682
When a completion happens in a key position and the value expression
is missing. This allows type checker to use TypeVariable so it increases
the chance to type check them successfully.
- Analyze the type of the literal in the context
- If ':' is missing in the literal, treat the expression as a key
expression
- If the parent expression is TupleExpr, analyze the context type of the
tuple first, then return the element type of the position
rdar://problem/57096392
Parameter evaluation order is unspecified, and MSVC happens to do it in
the opposite order than Clang.
Move the evaluation of the parameters outside the invocation, so the
order is clear, and the token consuming happens in the right order.
* WIP implementation
* Cleanup implementation
* Install backedge rather than storing array reference
* Add diagnostics
* Add missing parameter to ResultFinderForTypeContext constructor
* Fix tests for correct fix-it language
* Change to solution without backedge, change lookup behavior
* Improve diagnostics for weak captures and captures under different names
* Remove ghosts of implementations past
* Address review comments
* Reorder member variable initialization
* Fix typos
* Exclude value types from explicit self requirements
* Add tests
* Add implementation for AST lookup
* Add tests
* Begin addressing review comments
* Re-enable AST scope lookup
* Add fixme
* Pull fix-its into a separate function
* Remove capturedSelfContext tracking from type property initializers
* Add const specifiers to arguments
* Address review comments
* Fix string literals
* Refactor implicit self diagnostics
* Add comment
* Remove trailing whitespace
* Add tests for capture list across multiple lines
* Add additional test
* Fix typo
* Remove use of ?: to fix linux build
* Remove second use of ?:
* Rework logic for finding nested self contexts
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.