Skip to content

rt: get rid of rust_fn and replace with fn_env_pair plus a little cleanup. - #4915

Closed
luqmana wants to merge 3 commits into
rust-lang:incomingfrom
luqmana:rt-cleanup
Closed

rt: get rid of rust_fn and replace with fn_env_pair plus a little cleanup.#4915
luqmana wants to merge 3 commits into
rust-lang:incomingfrom
luqmana:rt-cleanup

Conversation

@luqmana

@luqmana luqmana commented Feb 13, 2013

Copy link
Copy Markdown
Contributor

Closes #1190.

Also, got rid of rust_ptr_eq since it isn't used any as well the RUST_REFCOUNTED macros.

Fixes #2667: alignment & wrong structure.

@luqmana

luqmana commented Feb 13, 2013

Copy link
Copy Markdown
Contributor Author

Fixed alignment and rebased on incoming.

r?

bors added a commit that referenced this pull request Feb 14, 2013
Closes #1190.

Also, got rid of `rust_ptr_eq` since it isn't used any as well the `RUST_REFCOUNTED` macros.

Fixes #2667: alignment & wrong structure.
@bors bors closed this Feb 14, 2013
RalfJung added a commit to RalfJung/rust that referenced this pull request Mar 30, 2026
…threads

Unblock all threads with exceeded timeouts at once
U007D pushed a commit to U007D/rust-mos that referenced this pull request Aug 21, 2026
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 rust-lang#4904 

4916: Warnings as hint or info r=matklad a=GabbeV

Fixes rust-lang#4229 

This PR is my second attempt at providing a solution to the above issue. My last PR(rust-lang#4721) had to be rolled back(rust-lang#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.
![image](https://user-images.githubusercontent.com/13839236/84830640-0bb8d900-b02a-11ea-9e2f-0561b0e8f1ef.png)
![image](https://user-images.githubusercontent.com/13839236/84826931-ffca1880-b023-11ea-8080-5e5b91a6ac0d.png)

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.
![image](https://user-images.githubusercontent.com/13839236/84827165-55062a00-b024-11ea-8bd6-bdbf1217c4c5.png)

### 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.
![image](https://user-images.githubusercontent.com/13839236/84829609-50437500-b028-11ea-80a8-1bbd05680ba7.png)

### 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants