Commit Graph

8 Commits

Author SHA1 Message Date
Alexander Cyon
a80b8ae06f [test/IDE] Fix typos 2024-08-08 19:35:00 +02:00
Alex Hoppen
f2017b82ac [IDE] Don't fallback type check if the completion expression is inside a closure 2023-07-07 19:51:01 +02:00
Alex Hoppen
32eff21977 [IDE] Remove "Begin completions" and "End completions" from test cases
These test lines weren't actually providing any value and were annoying to write. Let's jut remove them.
2023-03-22 09:07:17 -07:00
Rintaro Ishizaki
154cd88c86 [CodeCompletion] Use 'Flair' to describe "is argument labels" 2021-06-07 17:25:01 -07:00
Rintaro Ishizaki
6dd5d9482f [CodeCompletion] Introduce "Flair" in code completion
To describe fine grained priorities.

Introduce 'CodeCompletionFlair' that is a set of more descriptive flags for
prioritizing completion items. This aims to replace '
SemanticContextKind::ExpressionSpecific' which was a "catch all"
prioritization flag.
2021-06-07 17:25:01 -07:00
Alex Hoppen
865e80f9c4 [CodeComplete] Default parameter names of completed closure to internal names
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.
2021-04-01 19:14:19 +02:00
Rintaro Ishizaki
17be66c3d6 [PlaceholderExpansion] Omit return type in closure signature
Return type in the closure signature is often redundant when expanding
placeholders, because the type of the clossures are usually inferred
from the context (i.e. calling function), users don't need to write the
return type explicitly.

They are not only redundant, but also sometimes harmful when the return
type is a generic parameter or its requirement. Actually, there is no
correct spelling in such cases.

So omit the return type and the parentheses around the parameter clause.

rdar://problem/63607976
2020-07-09 14:37:17 -07:00
Ben Langmuir
37b98af4e6 [CodeCompletion] Pre-expand closures in argument completion
When completing a single argument for a trailing closure, pre-expand the
closure expression syntax instead of using a placeholder. It's not valid
to pass a non-closure anyway.

rdar://62189182
2020-05-06 01:56:41 -04:00