9718: Bump notify to 5.0.0-pre.11 r=lnicola a=deontologician
It looks like the `INotifyWatcher::new` method was removed sometime after `5.0.0-pre.3` and then added back in `5.0.0-pre.11`. Without the `=`, cargo can resolve some version from `5.0.0-pre.4` -> `5.0.0-pre.10` which will not compile.
Co-authored-by: Josh Kuhn <deontologician@gmail.com>
9716: internal: Stop reexporting `hir_def`'s `ItemInNs` from HIR r=jonas-schievink a=jonas-schievink
Resolves a FIXME and simplifies downstream code
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9700: fix: Remove the legacy macro scoping hack r=matklad a=jonas-schievink
This stops prepending `self::` to single-ident macro paths, resolving even legacy-scoped macros using the fixed-point algorithm. This is not correct, but a lot easier than fixing this properly (which involves pushing a new scope for every macro definition and invocation).
This allows resolution of macros from the prelude, fixing https://github.com/rust-analyzer/rust-analyzer/issues/9687.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9693: feat: Add the Hover Range capability which enables showing the type of an expression r=matklad a=alexfertel
Closes https://github.com/rust-analyzer/rust-analyzer/issues/389
This PR extends the `textDocument/hover` method to allow getting the type of an expression. It looks like this:
![type_of_expression](https://user-images.githubusercontent.com/22298999/126914293-0ce49a92-545d-4005-a59e-9294fa2330d6.gif)
Edit: One thing I noticed is that when hovering a selection that includes a macro it doesn't work, so maybe this would need a follow-up issue discussing what problem that may have.
(PS: What a great project! I am learning a lot! 🚀)
Co-authored-by: Alexander Gonzalez <alexfertel97@gmail.com>
Co-authored-by: Alexander González <alexfertel97@gmail.com>
9703: docs: Fix several typos and grammar mistakes r=matklad a=alexfertel
I took some time to clean up the dev docs a bit since I spent the whole week reading them. I am not a native speaker, so if you find something wrong please tell me and I'll fix it 😁
Co-authored-by: Alexander Gonzalez <alexfertel97@gmail.com>
9701: fix: correctly update diagnostics when files are opened and closed r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
9558: Do not erase Cargo diagnostics from the closed documents r=matklad a=SomeoneToIgnore
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/6850
The LSP specification at https://microsoft.github.io/language-server-protocol/specifications/specification-3-14/#textDocument_publishDiagnostics states that
> Diagnostics notification are sent from the server to the client to signal results of validation runs.
>
> Diagnostics are “owned” by the server so it is the server’s responsibility to clear them if necessary. The following rule is used for VS Code servers that generate diagnostics:
>
> * if a language is single file only (for example HTML) then diagnostics are cleared by the server when the file is closed.
> * if a language has a project system (for example C#) diagnostics are not cleared when a file closes. When a project is opened all diagnostics for all files are recomputed (or read from a cache).
>
> When a file changes it is the server’s responsibility to re-compute diagnostics and push them to the client. If the computed set is empty it has to push the empty array to clear former diagnostics. Newly pushed diagnostics always replace previously pushed diagnostics. There is no merging that happens on the client side.
So for projects we should not clear any diagnostics from cargo/json projects.
Our "standalone file" mode is in a way a project too, with sysroot attached and a potential support for dynamic standalone files.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
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>