9593: fix: Adding remove_unused_param for method and fixing same for assoc func r=matklad a=feniljain
Solves #9571
Co-authored-by: vi_mi <fenil.jain2018@vitstudent.ac.in>
9692: Use same cancelled spelling in doc and code. r=matklad a=mattiasgronlund
Right thing might be to update the spelling in the code to
follow American instead of English spelling, that is
using only canceled. But they should at least be aligned.
Co-authored-by: Mattias Grönlund <mattias@gronlund.se>
Right thing might be to update the spelling in the code to
follow American instead of English spelling, that is
using only canceled. But they should at least be aligned.
9691: fix: Keep catch-all arm in fill_match_arms if it has a non-empty expression r=Veykril a=Veykril
Fixes#4165
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9685: internal: add tests for tuple struct field completion and resolve a FIXME r=jonas-schievink a=jonas-schievink
This removes the last FIXME related to visibility and thus fixes https://github.com/rust-analyzer/rust-analyzer/issues/824
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9684: Complete editable private items r=jonas-schievink a=jonas-schievink
This checks if a private item's location is editable (local source root), and completes them anyways if that's the case.
In order to test this, the `new_source_root` fixture command has been changed to take a `local` or `library` value, and to apply to all *following* files instead of the preceding ones (which would be hard to understand).
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9681: Respect `#[doc(hidden)]` in dot-completion r=jonas-schievink a=jonas-schievink
This adds `CompletionContext::is_visible` as a convenience method that checks visibility, presence of `doc(hidden)`, and whether the completed item is in the same crate as the completion site or not. We only complete `doc(hidden)` items from the same crate.
This doesn't yet work for *all* completions: `qualified_path` completions use `Module::scope` and `ScopeDef`, which doesn't work with this.
Part of https://github.com/rust-analyzer/rust-analyzer/issues/7718
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9678: Add Configuration for Highlight Related Feature r=kdelorey a=kdelorey
# Summary
Adds basic configuration that allows you to control when the highlight related feature is activated. You can control this for references, break points, exit points, and yield points.
Resolves#9618
![config](https://user-images.githubusercontent.com/2295721/126728849-a38b560c-b687-42c1-9c41-7584ad718469.gif)
Co-authored-by: Kevin DeLorey <kdelorey.dev@gmail.com>
9675: internal: Move and clean up record completion tests r=Veykril a=Veykril
Now all that's left are the expression related tests which will take some time to go through
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9674: fix: Fix pattern name resolution when name is also occupied in type namespace r=flodiebold a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/8694
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9634: minor update to excludeDirs doc r=lnicola a=dae
I saw reference to globs in #7755, but it doesn't look like they're
actually supported, and I had to dig through the source to discover
that the folders are relative to the workspace root. Further digging
was required to get VS Code from hanging for long periods trying to
watch giant Bazel folders that had already been excluded from Rust
Analyzer. Hopefully this tweak will save others the confusion :-)
Co-authored-by: Damien Elmes <gpg@ankiweb.net>
Co-authored-by: Damien Elmes <dae@users.noreply.github.com>
9453: Add first-class limits. r=matklad,lnicola a=rbartlensky
Partially fixes#9286.
This introduces a new `Limits` structure which is passed as an input
to `SourceDatabase`. This makes limits accessible almost everywhere in
the code, since most places have a database in scope.
One downside of this approach is that whenever you query limits, you
essentially do an `Arc::clone` which is less than ideal.
Let me know if I missed anything, or would like me to take a different approach!
Co-authored-by: Robert Bartlensky <bartlensky.robert@gmail.com>