4913: Remove debugging code for incremental sync r=matklad a=lnicola
4915: Inspect markdown code fences to determine whether to apply syntax highlighting r=matklad a=ltentrup
Fixes#4904
4916: Warnings as hint or info r=matklad a=GabbeV
Fixes#4229
This PR is my second attempt at providing a solution to the above issue. My last PR(#4721) had to be rolled back(#4862) due to it overriding behavior many users expected. This PR solves a broader problem while trying to minimize surprises for the users.
### Problem description
The underlying problem this PR tries to solve is the mismatch between [Rustc lint levels](https://doc.rust-lang.org/rustc/lints/levels.html) and [LSP diagnostic severity](https://microsoft.github.io/language-server-protocol/specification#diagnostic). Rustc currently doesn't have a lint level less severe than warning forcing the user to disable warnings if they think they get to noisy. LSP however provides two severitys below warning, information and hint. This allows editors like VSCode to provide more fine grained control over how prominently to show different diagnostics.
Info severity shows a blue squiggly underline in code and can be filtered separately from errors and warnings in the problems panel.
Hint severity doesn't show up in the problems panel at all and only show three dots under the affected code or just faded text if the diagnostic also has the unnecessary tag.
### Solution
The solution provided by this PR allows the user to configure lists of of warnings to report as info severity and hint severity respectively. I purposefully only convert warnings and not errors as i believe it's a good idea to have the editor show the same severity as the compiler as much as possible.
### Open questions
#### Discoverability
How do we teach this to new and existing users? Should a section be added to the user manual? If so where and what should it say?
#### Defaults
Other languages such as TypeScript report unused code as hint by default. Should rust-analyzer similarly report some problems as hint/info by default?
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
Co-authored-by: Gabriel Valfridsson <gabriel.valfridsson@gmail.com>
4909: Anchor file-system operations to the file, and not to the source root. r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Anchoring to the SourceRoot wont' work if the path is absolute:
#[path = "/tmp/foo.rs"]
mod foo;
Anchoring to a file will.
However, we *should* anchor, instead of just producing an abs path.
I can imagine a situation where, for example, rust-analyzer processes
crates from different machines (or, for example, from in-memory git
branch), where the same absolute path in different crates might refer
to different files in the end!
4908: Fix typos in docs/dev/README.md r=kjeremy a=okaneco
Small grammar and spelling changes in the README.md for the dev docs.
Co-authored-by: okaneco <47607823+okaneco@users.noreply.github.com>
4876: Syntactic highlighting of NAME_REF for injections r=matklad a=ltentrup
This commit adds a function that tries to determine the syntax highlighting class of NAME_REFs based on the usage.
It is used for highlighting injections (such as highlighting of doctests) as the semantic logic will most of the time result in unresolved references.
It also adds a color to unresolved references in HTML encoding.
Follow up of #4683.
Fixes#4809.
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
This commit adds a function that tries to determine the syntax highlighting class of NAME_REFs based on the usage.
It is used for highlighting injections (such as highlighting of doctests) as the semantic logic will most of the time result in unresolved references.
It also adds a color to unresolved references in HTML encoding.
4860: Accept relative paths in rust-project.json r=matklad a=tweksteen
If a relative path is found as part of Crate.root_module or Root.path, interpret it as relative to the location of the rust-project.json file.
Fixes: #4816
Co-authored-by: Thiébaud Weksteen <tweek@google.com>
4892: Make ra_syntax::{SyntaxNodeChildren, SyntaxElementChildren} public. r=matklad a=davidlattimore
SyntaxNode::children and SyntaxNode::children_with_tokens return these types, but there's currently no way AFAIK to name them.
Co-authored-by: David Lattimore <dml@google.com>
4893: Add Embark Studios to the sponsors list r=matklad a=matklad
Forgot to do this when updating the sponsors list on the website the
last time :(
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
4882: _match.rs: improve comment formatting r=matklad a=jonas-schievink
This results in much nicer rustdoc output
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
4880: "fill match arms" assist: Match on bind patterns r=flodiebold a=tobz1000
This prevents duplication of match arms where the pre-existing arm is a bind pattern.
Co-authored-by: Toby Dimmick <tobydimmick@pm.me>
4875: Introduce paths crate r=matklad a=matklad
It's a good idea to distinguish between absolute and relative paths at
the type level, to avoid accidental dependency on the cwd, which
really shouldn't matter for rust-analyzer service
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
It's a good idea to distinguish between absolute and relative paths at
the type level, to avoid accidental dependency on the cwd, which
really shouldn't matter for rust-analyzer service
