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.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
We need to teach code completion how to invoke the type checker for attached macro attributes. After that, everything started working.
rdar://105232015
When completing after `names:`, completion should offer the different ways you can specify the names, i.e. `arbitrary`, `named`, etc.
```
@freestanding(declaration, names: #^COMPLETE^#)
```
rdar://108535077
Only return macros that are valid in their current position, ie. an
attached macro is not valid on a nominal.
Also return freestanding expression macros in code block item position
and handle the new freestanding code item macros.
Resolves rdar://105563583.
Calling getImportedModules requires to list the desired kind of imports.
With the new kind of imports this has become cumbersome. Let's simplify
it by offering common sets of imports. Advanced call sites can still
list the desired imports explicitly.
Cursor info only cares about the `doneParsing` callback and not about all the `complete` functions that are now defined in `CodeCompletionCallbacks`. To make the design clearer, split `IDEInspectionCallbacks`.
rdar://105120332
We need the ability to type check declarations when entering using `typeCheckASTNodeAtLoc` for solver-based cursor info.
This causes more context to be type checked for code completion and breaks some type completion after dot if the base type is not fully qualified because the type checker will mark `TypeRepr` as invalid. But since we don’t actually need to run the type checker for type member completion, we can just not call `typeCheckContextAt` for `TypeIdentifierWithDot` completions.
This will be necessary to make cursor info completion like to inspect the just parsed source file because the callback from parsing the code completion token won’t be called.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Store whether a result is async in the `ContextFreeCodeCompletionResult` and determine whether an async method is used in a sync context when promoting the context free result to a contextual result.
rdar://78317170
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
The code completion might occur inside an attriubte that isn’t part of the AST because it’s missing a `VarDecl` that it could be attached to. In these cases, record the `CustomAttr` and type check it standalone, pretending it was part of a `DeclContext`.
This also fixes a few issues where code completion previously wouldn’t find the attribute constructor call and thus wasn’t providing code completion inside the property wrapper.
rdar://92842803
When completing after `@`, record what kind of attributes are applicable here (property wrapper, result builder, global actor), mark types that are marked as property wrapper etc. as having a 'Convertible' type relation and mark all other types as having an invalid type relation.
rdar://78239501
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
