For example for:
funcName(base.<HERE>)
Wrap 'base' with 'CodeCompletionExpr' so that type checker can check
'base' independently without preventing the overload choice of 'funcName'.
This increases the chance of successful type checking.
rdar://problem/63965160
Reverse the polarity of the "checked in context" bit for ClosureExpr
to "separately checked", which simplifies the AST walker logic (to
"should we walk separately type-checked closure bodies?") and
eliminates single-expression closures as a separate case to consider.
Rather than using various "applied function builder" and "is single
expression body" checks to determine whether a closure was
type-checked in its enclosing expression, record in the closure
expression whether it actually *was* type-checked as part of its
enclosing expression.
This restores getSourceRange() on DefaultArgumentExpr after it was removed in
https://github.com/apple/swift/pull/31184.
It was originally removed to solve the issues it was causing when computing the
source range of its parent TupleExpr. To account for trailing closures we walk
back through the tuple's arguments until one with a valid location is found,
which we use as the end location. If the last argument was a DefaultArgumentExpr
though that meant the end loc would end up being the tuple's start location, so
none of the tuple's other arguments were contained in its range, triggering an
ASTVerifier assertion. Source tooling and diagnostics don't care about default
arg expression locations as nothing can reference them, but their locations are
output in the debug info. Added a regression test to catch that in future, and
updated TupleExpr::getSourceRange() to ignore them when computing the end loc.
Resolves rdar://problem/63195504.
that allows arbitrary `label: {}` suffixes after an initial
unlabeled closure.
Type-checking is not yet correct, as well as code-completion
and other kinds of tooling.
Accept trailing closures in following form:
```swift
foo {
<label-1>: { ... }
<label-2>: { ... }
...
<label-N>: { ... }
}
```
Consider each labeled block to be a regular argument to a call or subscript,
so the result of parser looks like this:
```swift
foo(<label-1>: { ... }, ..., <label-N>: { ... })
```
Note that in this example parens surrounding parameter list are implicit
and for the cases when they are given by the user e.g.
```swift
foo(bar) {
<label-1>: { ... }
...
}
```
location of `)` is changed to a location of `}` to make sure that call
"covers" all of the transformed arguments and parser result would look
like this:
```swift
foo(bar,
<label-1>: { ... }
)
```
Resolves: rdar://problem/59203764
Also extend returned object from simplify being an expression to
`TrailingClosure` which has a label, label's source location and
associated closure expression.
If any arguments were defaulted the tuple/paren was made implicit, even though
the original tuple/paren was present in the source.
This prevented some sourcekit ASTWalkers from considering them, making
refactorings, documentation info, jump-to-definition and other features
unavailable when queried via their argument labels.
Resolves rdar://problem/62118957
Remove duplication in the modeling of TypeExpr. The type of a TypeExpr
node is always a metatype corresponding to the contextual
type of the type it's referencing. For some reason, the instance type
was also stored in this TypeLoc at random points in semantic analysis.
Under the assumption that this instance type is always going to be the
instance type of the contextual type of the expression, introduce
a number of simplifications:
1) Explicit TypeExpr nodes must be created with a TypeRepr node
2) Implicit TypeExpr nodes must be created with a contextual type
3) The typing rules for implicit TypeExpr simply opens this type
wrapped value placeholder in an init(wrappedValue:) call that was previously
injected as an OpaqueValueExpr. This commit also restores the old design of
OpaqueValueExpr.
Add the `@differentiable` function conversion pipeline:
- New expressions that convert between `@differentiable`,
`@differentiable(linear)`, and non-`@differentiable` functions:
- `DifferentiableFunction`
- `LinearFunction`
- `DifferentiableFunctionExtractOriginal`
- `LinearFunctionExtractOriginal`
- `LinearToDifferentiableFunction`
- All the AST handling (e.g. printing) necessary for those expressions.
- SILGen for those expressions.
- CSApply code that inserts these expressions to implicitly convert between
the various function types.
- Sema tests for the implicit conversions.
- SILGen tests for the SILGen of these expressions.
Resolves TF-833.
This restructures the indentation logic around producing a single IndentContext
for the line being indented. An IndentContext has:
- a ContextLoc, which points to a source location to indent relative to,
- a Kind, indicating whether we should align with that location exactly, or
with the start of the content on its containing line, and
- an IndentLevel with the relative number of levels to indent by.
It also improves the handling of:
- chained and nested parens, braces, square brackets and angle brackets, and
how those interact with the exact alignment of parameters, call arguments,
and tuple, array and dictionary elements.
- Indenting to the correct level after an incomplete expression, statement or
decl.
Resolves:
rdar://problem/59135010
rdar://problem/25519439
rdar://problem/50137394
rdar://problem/48410444
rdar://problem/48643521
rdar://problem/42171947
rdar://problem/40130724
rdar://problem/41405163
rdar://problem/39367027
rdar://problem/36332430
rdar://problem/34464828
rdar://problem/33113738
rdar://problem/32314354
rdar://problem/30106520
rdar://problem/29773848
rdar://problem/27301544
rdar://problem/27776466
rdar://problem/27230819
rdar://problem/25490868
rdar://problem/23482354
rdar://problem/20193017
rdar://problem/47117735
rdar://problem/55950781
rdar://problem/55939440
rdar://problem/53247352
rdar://problem/54326612
rdar://problem/53131527
rdar://problem/48399673
rdar://problem/51361639
rdar://problem/58285950
rdar://problem/58286076
rdar://problem/53828204
rdar://problem/58286182
rdar://problem/58504167
rdar://problem/58286327
rdar://problem/53828026
rdar://problem/57623821
rdar://problem/56965360
rdar://problem/54470937
rdar://problem/55580761
rdar://problem/46928002
rdar://problem/35807378
rdar://problem/39397252
rdar://problem/26692035
rdar://problem/33760223
rdar://problem/48934744
rdar://problem/43315903
rdar://problem/24630624
When wrapping a function which is supposed to capture the caller’s location, there’s always a risk that the wrapper won’t capture the information the wrapped function wants; for instance, you might pass `(…, line, column)` where the callee expected `(…, column, line)`.
This commit emits a warning when a call passes an explicit argument to something that has a default argument, and that explicit argument is itself a parameter with a default argument, and both parameters use magic identifiers, but they use *different* magic identifiers. This is partially in support of concise #file, but applies to all magic identifiers.
Fixes rdar://problem/58588633.
We used to get this contextualization "for free" because closures that
had function builders applied to them would get translated into
single-expression closures. Now, we need to check for this explicitly.
The type checking of the for-each loop is split between the constraint
solver (which does most of the work) and the statement checker (which
updates the for-each loop AST). Move more of the work into the constraint
solver proper, so that the AST updates can happen in one place, making use
of the solution produced by the solver. This allows a few things, some of
which are short-term gains and others that are more future-facing:
* `TypeChecker::convertToType` has been removed, because we can now either
use the more general `typeCheckExpression` entry point or perform the
appropriate operation within the constraint system.
* Solving the constraint system ensures that everything related to the
for-each loop full checks out
* Additional refactoring will make it easier for the for-each loop to be
checked as part of a larger constraint system, e.g., for processing entire
closures or function bodies (that’s the futurist bit).
* 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.
This change adds UnresolvedDotExpr::createImplicit() and UnresolvedDeclRefExpr::createImplicit() helpers. These calls simplify several tedious bits of code synthesis that would otherwise become even more tedious with DeclNameRef in the picture.
