Defining it as a `DECL_KEYWORD` means code
completion will try and complete it in decl
position. It shouldn't really be considered a decl
keyword, so define it as `SWIFT_KEYWORD`.
Don't suggest `let` or `var` in e.g the sequence
expression of a `for` loop, or after a `return`.
We ought to do a better job of checking whether
we're in expression position before suggesting
these (as opposed to a pattern), but I'm leaving
that as future work for now.
Fix the common error of using underscores instead of dashes.
In the rebranch this is an error (lit got more picky), but it also makes sense to fix the tests in the main branch
func test(value: [Int]) {
value.map { value <HERE> }
}
In this case 'value' in the closure is ambiguous between an expression
referring the outer function parameter, or a parameter declaration in
the closure. Previously, code completion only considered the former and
suggest the members of '[Int]', but not 'in' keyword. As a result, when
the user actually want to type 'in' here, they needed to hit 'esc' to
cancel the code completion.
In this change, suggest 'in' keyword even without a newline, as long as
the current decl context is a closure and it doesn't have 'in' in it.
Also previously 'in' was suggested even outside the closure and even it
already had the explict 'in'. This PR limit suggesting 'in' inside
closures without explicit 'in'.
rdar://80489548
Previously 'actor' keyword was suggested as (deprecated) 'actor' decl
modifier, and it was gated by '-enable-experimental-concurrency'
compiler argument.
Add 'actor' as a type decl introducer. This causes duplicated 'actor' in
code completion if '-enable-experimental-concurrency', but that option
is basically useless at this point, so I assume not many people is using
it. Also 'actor' as a modifier will be removed soon.
[#58520] rdar://92511769
I think that preferring identical over convertible makes sense in e.g. C++ where we have implicit user-defined type conversions but since we don’t have them in Swift, I think the distinction doesn’t make too much sense, because if we have a `func foo(x: Int?)`, want don’t really want to prioritize variables of type `Int?` over `Int` Similarly if we have `func foo(x: View)`, we don’t want to prioritize a variable of type `View` over e.g. `Text`.
rdar://91349364
Instead of setting the code completion position when parsing the if-statement, which doesn’t create a `CodeCompletionExpr`, parse it as a new top-level expression.
As far as test-cases are concerned, this removes the “RareKeyword” flair from top-level completions in the modified test case. This makes sense IMO.
* 'super' in a overriding decl is "common".
* type decl introducers (e.g. 'struct', 'enum') at top-level in library
files are "common"
* type decl introducers in 'protocol' are invalid, hence "rare"
* top-level only decl introducer (e.g. 'import', 'extension') are invalid
at non-top-level, hence "rare"
* nested types in function bodies are "rare"
* member only decls (e.g. 'subscript', 'deinit') are invalid in function
body, hence "rare"
* some modifiers (e.g. 'public', 'private', 'override') are invalid for
local decls, hence "rare"
rdar://77934651
At some point we stopped completing keywords after `else` in an if
statement. Bring back the completion of `if`, which is the only valid
continuation other than a brace.
rdar://37467474
When completing in an if/while/guard statement condition that expects a
boolean, add the code-completion type relation for Bool. We already had
this for repeat-while.
rdar://problem/26509084
There was a ton of complicated logic here to work around
two problems:
- Same-type constraints were not represented properly in
RequirementReprs, requiring us to store them in strong form
and parse them out when printing type interfaces.
- The TypeBase::getAllGenericArgs() method did not do the
right thing for members of protocols and protocol extensions,
and so instead of simple calls to Type::subst(), we had
an elaborate 'ArchetypeTransformer' abstraction repeated
in two places.
Rewrite this code to use GenericSignatures and
GenericFunctionType instead of old-school GenericParamLists
and PolymorphicFunctionType.
This changes the code completion and AST printer output
slightly. A few of the changes are actually fixes for cases
where the old code didn't handle substitutions properly.
A few others are subjective, for example a generic parameter
list of the form <T : Proto> now prints as <T where T : Proto>.
We can add heuristics to make the output whatever we want
here; the important thing is that now we're using modern
abstractions.
Ideally we would have precise completion for all our keywords; for now,
just imporove handling of 'return', which we can do by checking if the
current context is a function/closure/init/subscript/etc.
rdar://problem/26307555
After this change,
extension P where WHERE1 { final func foo() {} }
extension P where WHERE2 { final func bar() { #^COMPLETE_HERE^#
will complete foo() if and only if WHERE2 is complatible with WHERE1.
Swift SVN r27480
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
