aboutsummaryrefslogtreecommitdiff
path: root/crates/ide/src/diagnostics
diff options
context:
space:
mode:
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>2021-03-15 12:59:47 +0000
committerGitHub <[email protected]>2021-03-15 12:59:47 +0000
commit0ac7a19d0c35f0c77a9c3a6209d8ff0e2cf1b035 (patch)
tree6e383cf36600b19ab2e69e7b7a62d132de4f8ba2 /crates/ide/src/diagnostics
parent6139bd764974318814edfd5427e2a2e8220b211b (diff)
parentd91151c3b1af6d4e4c29f5f82df8566b046266e3 (diff)
Merge #8008
8008: Completion context expected type r=matklad a=JoshMcguigan Currently there are two ways completions use to determine the expected type. There is the `expected_type` field on the `CompletionContext`, as well as the `expected_name_and_type` method on the `RenderContext`. These two things returned slightly different results, and their results were only valid if you had pre-checked some (undocumented) invariants. A simple combination of the two approaches doesn't work because they are both too willing to go far up the syntax tree to find something that fits what they are looking for. This PR makes the following changes: 1. Updates the algorithm that sets `expected_type` on `CompletionContext` 2. Adds `expected_name` field to `CompletionContext` 3. Re-writes the `expected_name_and_type` method to simply return the underlying fields from `CompletionContext` (I'd like to save actually removing this method for a follow up PR just to keep the scope of the changes down) 4. Adds unit tests for the `expected_type`/`expected_name` fields All the existing unit tests still pass (unmodified), but this new algorithm certainly has some gaps (although I believe all the `FIXME` introduced in this PR are also flaws in the current code). I wanted to stop here and get some feedback though - is this approach fundamentally sound? Co-authored-by: Josh Mcguigan <[email protected]>
Diffstat (limited to 'crates/ide/src/diagnostics')
0 files changed, 0 insertions, 0 deletions