aboutsummaryrefslogtreecommitdiff
path: root/crates/assists/src/utils.rs
Commit message (Collapse)AuthorAgeFilesLines
* Rename expr -> tail_exprAleksey Kladov2021-01-051-1/+1
|
* Merge #7115bors[bot]2021-01-031-4/+8
|\ | | | | | | | | | | | | | | | | | | | | | | | | 7115: Migrate HasSource::source to return Option r=matklad a=nick96 I've made a start on fixing #6913 based on the provided work plan, migrating `HasSource::source` to return an `Option`. The simple cases are migrated but there are a few that I'm unsure exactly how they should be handled: - Logging the processing of functions in `AnalysisStatsCmd::run`: In verbose mode it includes the path to the module containing the function and the syntax range. I've handled this with an if-let but would it be better to blow up here with `expect`? I'm not 100% on the code paths but if we're processing a function definition then the source should exist. I've handled `source()` in all code paths as `None` being a valid return value but are there some cases where we should just blow up? Also, all I've done is bubble up the returned `None`s, there may be some places where we can recover and still provide something. Co-authored-by: Nick Spain <[email protected]> Co-authored-by: Nick Spain <[email protected]>
| * Handle missing source in filter_assoc_itemsNick Spain2021-01-021-7/+8
| |
| * Mark HasSource::source_old as deprecated but allow at all call sitesNick Spain2021-01-021-4/+7
| |
| * HasSource::source -> HasSource::source_oldNick Spain2021-01-021-3/+3
| | | | | | | | To start migrating HasSource::source to return an Option.
* | Fix warnings on rust-nightlycynecx2021-01-021-1/+1
|/
* Remove parentheses when inverting `!(cond)`Jesse Bakker2020-12-211-1/+7
|
* Parenthesize composite if condition before inverting in invert-if assistJesse Bakker2020-12-151-0/+4
|
* Extract the import code into the shared moduleKirill Bulatov2020-11-271-199/+1
|
* Profile completions betterKirill Bulatov2020-11-271-0/+1
|
* Merge #6553bors[bot]2020-11-171-2/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6553: Auto imports in completion r=matklad a=SomeoneToIgnore ![completion](https://user-images.githubusercontent.com/2690773/99155339-ae4fb380-26bf-11eb-805a-655b1706ce70.gif) Closes https://github.com/rust-analyzer/rust-analyzer/issues/1062 but does not handle the completion order, since it's a separate task for https://github.com/rust-analyzer/rust-analyzer/issues/4922 , https://github.com/rust-analyzer/rust-analyzer/issues/4922 and maybe something else. 2 quirks in the current implementation: * traits are not auto imported during method completion If I understand the current situation right, we cannot search for traits by a **part** of a method name, we need a full name with correct case to get a trait for it. * VSCode (?) autocompletion is not as rigid as in Intellij Rust as you can notice on the animation. Intellij is able to refresh the completions on every new symbol added, yet VS Code does not query the completions on every symbol for me. With a few debug prints placed in RA, I've observed the following behaviour: after the first set of completion suggestions is received, next symbol input does not trigger a server request, if the completions contain this symbol. When more symbols added, the existing completion suggestions are filtered out until none are left and only then, on the next symbol it queries for completions. It seems like the only alternative to get an updated set of results is to manually retrigger it with Esc and Ctrl + Space. Despite the eerie latter bullet, the completion seems to work pretty fine and fast nontheless, but if you have any ideas on how to make it more smooth, I'll gladly try it out. Co-authored-by: Kirill Bulatov <[email protected]>
| * Add imports in auto completionKirill Bulatov2020-11-161-2/+1
| |
* | Add **Ignore Test** assistAleksey Kladov2020-11-171-0/+18
|/
* add suggestion ..Default::default() for remaining struct fields in a ↵Benjamin Coenen2020-11-131-1/+1
| | | | | | constructor #6492 Signed-off-by: Benjamin Coenen <[email protected]>
* add suggestion ..Default::default() for remaining struct fields in a ↵Benjamin Coenen2020-11-131-1/+11
| | | | | | constructor #6492 Signed-off-by: Benjamin Coenen <[email protected]>
* Add missing AssocItems in add_custom_impl assistLukas Wirth2020-11-051-3/+89
|
* Remove dependency on 'assists' from 'completion' crateIgor Aleksanov2020-10-241-118/+3
|
* Don't rely on display names in inlay_hintsAleksey Kladov2020-10-201-11/+14
|
* Rename declaration_name -> display_nameAleksey Kladov2020-10-201-1/+1
| | | | | | | | Declaration names sounds like a name of declaration -- something you can use for analysis. It empathically isn't, and is just a label displayed in various UI. It's important not to confuse the two, least we accidentally mix semantics with UI (I believe, there's already a case of this in the FamousDefs at least).
* Extract ImportAssets out of auto_importLukas Wirth2020-10-131-0/+1
|
* Clean up inlay_hintsLukas Wirth2020-10-071-1/+12
|
* Shorten iterator hints for std::iter iterators behind referencesLukas Wirth2020-10-071-1/+1
|
* Shorten iterator chain hintsLukas Wirth2020-10-071-7/+34
|
* Move IntoIterator into FamousDefsLukas Wirth2020-10-071-8/+15
|
* Use FamousDefs for shorten_iterator hintLukas Wirth2020-10-061-12/+49
|
* Move ModPath->ast::Path function to IDE layerAleksey Kladov2020-10-061-0/+21
| | | | closes #6092
* Make MergeBehaviour configurableLukas Wirth2020-09-121-1/+2
|
* Fix import insertion breaking nested modulesLukas Wirth2020-09-031-1/+1
|
* Impl make::blank_lineLukas Wirth2020-09-031-1/+1
|
* Cleanup invert-ifAleksey Kladov2020-08-251-19/+14
| | | | | * stick to trivial factory functions in make * compress the logic for inverting Option/Result
* Invert if should be smart about is_some, is_none, is_ok, is_errdragfire2020-08-241-1/+20
|
* **Remove Unused Parameter** refactoringAleksey Kladov2020-08-191-1/+5
|
* Rename ra_assists -> assistsAleksey Kladov2020-08-131-0/+313