When a function declaration has no body (e.g. because it’s a protocol requirement), we construct the range to replace by the `async` keyword as follows:
- Start: One character after the closing `)` (or potentially the `throws` keyword if it exists)
- End: Last token in the function declaration
Since the last token in the function declaration is the `)`, we end up with a range that has `End < Start`, which crashes when trying to print the range.
If the function has no body, we should just use the range’s start location as the end location to construct an empty range.
Fixes rdar://76677035
Combine IsNotRecommended with NotRecommendedReason and improve the names
of the existing cases to more clearly identify the cases they apply to.
Now all not-recommended completions are required to have a reason.
The diagnosticc engine is keeping track of state which might modify parsing/typechecking behaviour. In the added test case the `fatalErrorOccurred` flag was during the first completion. The flag was still `true` for the second completion, causing parsing/typechecking to behave slightly differently. Because of this, the ExprRewriter failed when applying a constraint system solution, not properly cleaning up its `ExprStack`.
This PR tackles both issues:
1) Reset the `hadError` flags in the diagnostics engine
2) Clean up the `ExprRewriter`’s `ExprStack` when rewriting a target fails.
Either of these changes fixes the crash in the test case but I think both could manifest through different code paths in different scenarios.
Fixes rdar://76051976 [SR-14430]
The actual fix is to perform qualified lookup on a TypeExpr in `collectPossibleCalleesForApply`.
This changes the behaviour of some test cases in `complete_multiple_trailingclosure.swift`, which now provide argument labels. To make the choices suggested less verbose, I refined the parameter matching to only match trailing closures to parameters of function types.
In `INIT_FALLBACK_1` we technically shouldn't be suggesting `arg3` based on the matched argument types (the closure returns `Int` and the constructor with `arg3` requires the closure to return `String`), but AFAICT we aren't doing type-checking at this stage, so there's no way to rule it out.
Various uses of `getPresumedLineAndColumnForLoc` were likely added when
that function was the very misleading name `getLineAndColumn`. Change
these to use `getLineAndColumnForBuffer` instead where appropriate, ie.
we want the underlying file rather than the location to display to the
user.
There were also some cases where the buffer identifier had been swapped
to use the display name instead, under the assumption that the presumed
location was needed. Updated those as well.
SingleRawComment: Lines are only used when merging comments, where the
original location is fine to use.
Index: Doesn't store the file set in #sourceLocation, so using the
presumed line would end up pointing to a location that makes no sense.
Editor functionality: Formatting and refactoring are on the current
file. Using the presumed location would result in incorrect
replacements.
Currently, if the code completion token is after a label that refers to a vararg, it is part of that VarargExpansionExpr, so we don’t suggest the subsequent parameter’s label.
Add special handling to detect this situation and suggest the parameter label.
Fixes rdar://76355192
If have a function that takes a trailing closure as follows
```
func sort(callback: (_ left: Int, _ right: Int) -> Bool) {}
```
completing a call to `sort` and expanding the trailing closure results in
```
sort { <#Int#>, <#Int#> in
<#code#>
}
```
We should be doing a better job here and defaulting the trailing closure's to the internal names specified in the function signature. I.e. the final result should be
```
sort { left, right in
<#code#>
}
```
This commit does exactly that.
Firstly, it keeps track of the closure's internal names (as specified in the declaration of `sort`) in the closure's type through a new `InternalLabel` property in `AnyFunctionType::Param`. Once the type containing the parameter gets canonicalized, the internal label is dropped.
Secondly, it adds a new option to `ASTPrinter` to always try and print parameter labels. With this option set to true, it will always print external paramter labels and, if they are present, print the internal parameter label as `_ <internalLabel>`.
Finally, we can use this new printing mode to print the trailing closure’s type as
```
<#T##callback: (Int, Int) -> Bool##(_ left: Int, _ right: Int) -> Bool#>
```
This is already correctly expanded by code-expand to the desired result. I also added a test case for that behaviour.
`SemaAnnotator` walks the tree in source order with respect to the source ranges *excluding* attributes, but `RangeResolver` considers attributes part of their declaration. Thus they disagree on what “walking in source order means”. `SemaAnnotator` will visit the attributes *before* the decl they are on, while `RangeResolver` as currently implemented expects them *as part of* the decl they are on.
Thus, for the purpose of `RangeResolver`, we need to assume that nodes are visited in arbitrary order and we might encounter enclosing nodes after their children.
Thus, when we find a new node, remove all nodes that it encloses from `ContainedASTNodes`.
Fixes rdar://64140713 [SR-12958]
We had some unbalanced calls of `walkTo*Pre` and `walkTo*Post` in `SemaAnnotator`.
The main fix was to set `Cancelled` to `true` if traversal is being stopped in `walkToExprPre`.
While I was at it, I also
- Added some more checks, ensuring that no more `walkTo*` calls are issued after `Cancelled` has been set to `true`.
- Added some comments, describing the intended traversal behaviour.
- Inverted the return value of the `ReportParamList` lambda to be in line with the return value of the enclosing `walkToDeclPre`
- Moved `walkToExprPost` to be place right after `walkToExprPre`
Resolves rdar://64139829 [SR-12957]
Cursor info for a constructor would previously give the cursor info for
the containing type only. It now also adds cursor info for the
constructor itself in a "secondary_symbols" field.
Refactor `passCursorInfoForDecl` to use a single allocator rather than
keeping track of positions in a buffer and assigning everything at the
end of the function.
Refactor the various available refactoring gathering functions to take a
SmallVectorImpl and to not copy strings where they don't need to.
Resolves rdar://75385556
For example, for
class C {
class D: C {
init() {}
}
}
let _: C = .#^HERE^#
We used to suggest 'D()' (not just 'D') because it was invalid without
initialization. However, after SE-0287, it can be valid. For example, if
'D' has:
extension C.D {
static var staticC: C { ... }
}
Users can write:
let _: C = .D.staticC
So we should not suggest constructor calls. Also, this is consistent with
normal type name completion. Users still can get initializer completions
by adding '(' after the type name.
Although initialization call completion with type names was convenient
in some cases, it's too annoying when we have unrelated member types
like:
enum MyEnum {
typealias Content = Int
case value(Content)
}
We don't want `.Content(bitPattern)` etc for implicit member completion
for 'MyEnum' context type.
rdar://75963052
Don't treat `actorIndependent(unsafe)` as its own kind of isolation.
It was only really used as a bring-up hack to break the isolation model,
but shouldn't be in the user model of the language and causes
complications to the implementation.
Previously, we always assumed that the position in the arguments would match the position in the parameter, which isn’t true in case of defaulted arguments. Try matching parameters based on argument labels to give better completion results.
Fixes rdar://60346573
The `init` of `self.init` needs to be looked up on the Metatype of `self`, not on the type of `self` itself. We were already doing a similar special-casing for `super.init`, which I extened to also cover `self.init`.
Resolves rdar://36521732
Adds two new fields to the cursor info response:
1. is_dynamic: whether a call is dynamic
2. receivers: receivers of the call (USRs)
Users of the CursorInfo request can use "is_dynamic" to decide whether
to lookup overrides or not, and then the "receivers" as the starting
point of the lookup.
Resolves rdar://75385900
The cursor info request also needs to output whether a call is "dynamic"
or not, move the functions related to this out of Index.cpp and into
IDE/Utils.cpp.
Also cleanup the `TrailingExpr` handling in `CursorInfoResolver` - it
only needs the first expression.
Introduce a new compiler flag `-module-abi-name <name>` that uses the
given name as the ABI name for the module (rather than the module's
name in source code). The ABI name impacts name mangling and metadata.
Checking for staticness is not enough because top-level decls count as
non-static yet do not have a sufficient curry level to satisfy this
check. Make sure we're looking for decls that reside inside of types.
rdar://75299825, SR-14327
While it is very convenient to default the ExtInfo state when creating
new function types, it also make the intent unclear to those looking to
extend ExtInfo state. For example, did a given call site intend to have
the default ExtInfo state or does it just happen to work? This matters a
lot because function types are regularly unpacked and rebuilt and it's
really easy to accidentally drop ExtInfo state.
By changing the ExtInfo state to an optional, we can track when it is
actually needed.
`visitTopLevelCodeDecl` ignored the `Stmt` visit returning a nullptr.
This caused the `walkToDeclPost` to run for the `TopLevelCodeDecl` and
thus an imbalance in the `RangeResolver` pre and posts (since none of
the children would have their `walkTo*Post` called).
This was originally incorrectly fixed while assuming that the
`walkTo*Post` are called regardless of whether the children were visited
or not. Those changes have been reverted - fixing an imbalance in
`ExtDecls` in `SemaAnnotator`.
Added a test case for the `ExtDecls` imbalance which can occur while an
extension is being added.
Resolves rdar://74820040
At the every usage of 'collectPossibleReturnTypesFromContext()', the
closure must have been typechecked earlier. If the closure has no
valid type at this point, there's no chance to be type-checked by
re-typechecking.
rdar://problem/74430478
Default arguments were still being visited when converting the call,
adding extra commas to the converted call. Skip over them.
Resolves rdar://74248990
Still convert the call if it was requested directly - only check the name
when converting a whole function. Once we have an attribute, we should
use that instead.
