aboutsummaryrefslogtreecommitdiff
path: root/crates/ide_completion
Commit message (Collapse)AuthorAgeFilesLines
...
| * Move more fields to `ImmediateLocation`Lukas Wirth2021-05-306-146/+163
| |
* | Fix incorrect prefer_inner calls on some attribute completionsLukas Wirth2021-05-301-6/+31
|/
* Only complete derive proc macros in `#[derive]`Jonas Schievink2021-05-291-2/+1
|
* Add some lint completion testsLukas Wirth2021-05-293-30/+67
|
* Merge #9027bors[bot]2021-05-294-359/+852
|\ | | | | | | | | | | | | | | | | | | | | 9027: feat: Attribute completion is context aware r=Veykril a=Veykril This splits off the `lint` and `derive` completions into their own submodules of `attribute`. The idea is to create a lazy global hashmap that maps `SyntaxKind` to attribute names(`&[&str]`) in which we index with the syntax kind of the "thing" we are attributing giving us the attributes back that are valid for this kind. Then we use this name to do a binary search on the attribute list to fetch and build the corresponding completion item. Co-authored-by: Lukas Wirth <[email protected]>
| * simplifyLukas Wirth2021-05-293-85/+92
| |
| * Add another attribute completion testLukas Wirth2021-05-281-5/+20
| |
| * Add attribute completion testsLukas Wirth2021-05-281-8/+399
| |
| * tt muncher timeLukas Wirth2021-05-273-27/+57
| |
| * Split attribute completion module into attribute, derive and lint modulesLukas Wirth2021-05-273-366/+302
| |
| * Attribute completion is context awareLukas Wirth2021-05-272-28/+142
| |
* | More completion pattern testsLukas Wirth2021-05-282-86/+109
| |
* | Implement prev sibling determination for `CompletionContext`Lukas Wirth2021-05-283-54/+114
| |
* | simplifyLukas Wirth2021-05-284-112/+117
| |
* | Don't label derive macros with their banged_nameLukas Wirth2021-05-281-1/+5
| |
* | Complete keywords in (Assoc)ItemList with leading attributeLukas Wirth2021-05-282-4/+33
| |
* | Only complete modules in empty use-statementsLukas Wirth2021-05-283-14/+27
|/
* Complete modules in item listsLukas Wirth2021-05-273-4/+45
|
* Complete modules in assoc item listsLukas Wirth2021-05-273-5/+13
|
* Cleanup `ImmediateLocation` determinationLukas Wirth2021-05-275-115/+132
|
* Don't complete non-macro item paths in impls and modulesLukas Wirth2021-05-276-29/+76
|
* simplifyLukas Wirth2021-05-277-36/+37
|
* simplifyLukas Wirth2021-05-272-18/+10
|
* Collapse more CompletionContext booleans into enumsLukas Wirth2021-05-276-98/+133
|
* Set `record_pat_syntax` more precisely in CompletionContextLukas Wirth2021-05-263-41/+58
|
* Merge #9015bors[bot]2021-05-264-80/+93
|\ | | | | | | | | | | | | | | | | 9015: Merge pattern completion related bools into an enum r=Veykril a=Veykril The two bools can never both be set so this is basically just a tri-state enum. bors r+ Co-authored-by: Lukas Wirth <[email protected]>
| * Merge pattern completion related bools into an enumLukas Wirth2021-05-264-80/+93
| |
* | Merge #9012bors[bot]2021-05-261-21/+29
|\ \ | |/ |/| | | | | | | | | | | 9012: feat: add tab stops for keyword completions r=matklad a=eduardocanellas Add tab stops for all the keywords that I judged fit. I also introduced some line breaks and spaces, following the pattern I saw in the `postfix` module. Co-authored-by: Eduardo Canellas <[email protected]>
| * feat: add tab stops for keyword completionsEduardo Canellas2021-05-261-21/+29
| |
* | simplifyLukas Wirth2021-05-263-67/+39
|/
* fix: remove undesired completions from trait/impl blocksEduardo Canellas2021-05-261-0/+2
|
* fix: don't show pd/ppd completions where it shouldn't beEduardo Canellas2021-05-252-11/+5
|
* internal: rename hypothetical -> speculativeAleksey Kladov2021-05-242-12/+12
| | | | | Lets steal this good naming from Roslyn before I forget about it yet again.
* Get rid of field_type againFlorian Diebold2021-05-231-4/+3
|
* Infer correct expected type in closureFlorian Diebold2021-05-231-1/+8
| | | | Sadly currently only works if the closure body isn't completely missing.
* Infer correct expected type for generic struct fieldsFlorian Diebold2021-05-232-16/+23
|
* Record method call substs and use them in call infoFlorian Diebold2021-05-231-0/+60
|
* Paper over #8931 a bit moreFlorian Diebold2021-05-231-0/+1
| | | | | | | | | The problem was the skipping of binders in `resolve_method_call_as_callable`; this still doesn't use the _correct_ substitution, but at least it doesn't return a type with free variables in it. Fixes #8931.
* Add test for #8931 and better checkingFlorian Diebold2021-05-231-0/+29
|
* Fix compilation of hir and ide cratesFlorian Diebold2021-05-211-1/+1
|
* Replace ImportGranularity::Guess with guessing boolean flagLukas Tobias Wirth2021-05-191-0/+1
|
* MergeBehavior -> ImportGranularityLukas Tobias Wirth2021-05-181-2/+5
|
* simplifyLukas Wirth2021-05-151-12/+10
|
* Merge #8794bors[bot]2021-05-101-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 8794: Give MergeBehaviour variants better names r=Veykril a=Veykril I never really liked the variant names I gave this enum from the beginning and then I found out about rustfmt's `imports_granularity` config: > imports_granularity > > How imports should be grouped into use statements. Imports will be merged or split to the configured level of granularity. > > Default value: Preserve > Possible values: Preserve, Crate, Module, Item > Stable: No I personally prefer using `crate` over `full` and `module` over last, they seem more descriptive. Keeping these similar between tooling also seems like a good plus point to me. We might even wanna take over the entire enum at some point if we have a `format/cleanup imports` assists in the future which would probably want to also have the `preserve` and `item` options. Co-authored-by: Lukas Wirth <[email protected]>
| * Give MergeBehaviour variants better namesLukas Wirth2021-05-101-1/+1
| |
* | Corrected 2 typos on line 83mixio2021-05-101-1/+1
|/
* Add `=` to pattern recoveryLukas Wirth2021-05-081-1/+22
|
* Small macro fixKirill Bulatov2021-05-061-1/+1
|
* internal: use API stabilized in 1.52Aleksey Kladov2021-05-061-1/+1
|
* SimplifyEdwin Cheng2021-05-061-6/+2
|