This has the benefit that in case of a code completion crash, we can see what kind of completion crashed without having to symbolicate the stack trace using LLDB.
It also made `trySolverCompletion` small enough that we can inline it into `doneParsing`, which makes debugging easier because you won’t accidentally step over the call to `trySolverCompletion`, which actually performs the completion.
Use FetchContent to include swift-syntax directly in swift. This can be
thought of as an `add_subdirectory` for a directory outside the root.
The default build directory will be `_deps/swiftsyntax-subbuild/`, though
the modules and shared libraries will be built in `lib/swift/host` by
passing down `SWIFT_HOST_LIBRARIES_DEST_DIR` to avoid copying them as we
were doing previously.
These allow multi-statement `if`/`switch` expression
branches that can produce a value at the end by
saying `then <expr>`. This is gated behind
`-enable-experimental-feature ThenStatements`
pending evolution discussion.
There's a subtle stack UAF here - `~CodeCompletionResultBuilder` would
be called *after* `~ExpectedTypeContext` as `ExpectedTypeContext` was
defined after `CodeCompletionResultBuilder`. Fix the order they're
created to prevent this.
This will allow us to run two different completion kinds and deliver results from both of them.
Also: Compute a unified type context for global lookup. Previously, we always used the expected type context of the last lookup. But really, we should be considering all possible types from all constraint system solutions when computing code completion results from the cache.
We didn’t actually have any tests for this. Completions aren’t great here at the moment but since this is an underscored language feature it’s not that important at the moment.
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
