diff options
author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2021-03-15 12:59:47 +0000 |
---|---|---|
committer | GitHub <[email protected]> | 2021-03-15 12:59:47 +0000 |
commit | 0ac7a19d0c35f0c77a9c3a6209d8ff0e2cf1b035 (patch) | |
tree | 6e383cf36600b19ab2e69e7b7a62d132de4f8ba2 /crates/profile/src | |
parent | 6139bd764974318814edfd5427e2a2e8220b211b (diff) | |
parent | d91151c3b1af6d4e4c29f5f82df8566b046266e3 (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/profile/src')
0 files changed, 0 insertions, 0 deletions