5917: Add a command to open docs for the symbol under the cursor r=matklad a=zacps
#### Todo
- [ ] Decide if there should be a default keybind or context menu entry
- [x] Figure out how to get the documentation path for methods and other non-top-level defs
- [x] Design the protocol extension. In future we'll probably want parameters for local/remote documentation URLs, so that should maybe be done in this PR?
- [x] Code organisation
- [x] Tests
Co-authored-by: Zac Pullar-Strecker <zacmps@gmail.com>
5858: Draft: Show reason for failed rename refactoring r=rherrmann a=rherrmann
Return an error with a meaningful message for requests to
`textDocument/rename` if the operation cannot be performed.
Pass errors, raised by rename handling code to the LSP runtime.
As a consequence, the VS Code client shows and logs the request
as if a server-side programming error occured.
Screenshot of a rename error showing in VS Code
![invalid-rename-ui](https://user-images.githubusercontent.com/607182/91059560-2c08a380-e62a-11ea-9297-f092db935a3b.png)
I would kindly ask to get feedback from the maintainers if they can spare the time:
* Is the general direction of the proposed changes acceptable?
* I'm new to Rust. The code feels clumsy and redundant, please suggest improvements
if you find the time for. E.g. is there a simple replacement for `RenameError`?
* Should presenting the error with proper severity (i.e. not as a programming error) be part of this change or in a followup change?
See https://github.com/rust-analyzer/rust-analyzer/issues/3981
Co-authored-by: Rüdiger Herrmann <ruediger.herrmann@gmx.de>
Return an error with a meaningful message for requests to
`textDocument/rename` if the operation cannot be performed.
Pass errors raised by rename handling code to the LSP runtime.
As a consequence, the VS Code client shows and logs the request
as if a server-side programming error occured.
Resolves https://github.com/rust-analyzer/rust-analyzer/issues/3981
6189: adt: correctly inherit field visibility from enum r=jonas-schievink a=jonas-schievink
Previously, "find all references" on a variant field wouldn't find any
references outside the defining module. This is because variant fields
were incorrectly assumed to be private, like struct fields without
explicit visibility, but they actually inherit the enum's visibility.
bors r+ 🤖
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Previously, "find all references" on a variant field wouldn't find any
references outside the defining module. This is because variant fields
were incorrectly assumed to be private, like struct fields without
explicit visibility, but they actually inherit the enum's visibility.
6188: Treat `ast::Name` in field patterns as use r=jonas-schievink a=jonas-schievink
bors r+ 🤖
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6185: Add note if RUST_SRC_PATH is likely to be wrong r=jonas-schievink a=jonas-schievink
bors r+ 🤖
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
5651: Add track_env_var to the proc macro server r=kjeremy a=lnicola
See https://github.com/rust-lang/rust/pull/74653.
Fixes#6054.
Fixes#5640, maybe.
Should be merged when 1.47 is released.
Proc macros still don't work for me, but it no longer crashes.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
Currently a method only has defaultness if it is a provided trait
method, but this will change when specialisation is available and may
need to become a concept known to hir.
I opted to go for a 'fewest changes' approach given specialisation is
still under development.
6161: Bump chalk to use latest git to get upstream fix r=jonas-schievink a=Ameobea
* Chalk very recently (like an hour ago) merged a fix that prevents rust analyzer from panicking. This allows it to be usable again for code that hits those situations. See #6134, #6145, Probably #6120
Co-authored-by: Casey Primozic <me@ameo.link>
6154: Shorten type hints for std::iter Iterators r=SomeoneToIgnore a=Veykril
Fixes#3750.
This re-exports the `hir_expand::name::known` module to be able to fetch the `Iterator` and `iter` names.
I'm not sure if there is anything to do with `Solution::Ambig` in `normalize_trait_assoc_type` or whether discarding those results is always wanted.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>