We don't host the textmate grammar for rust, that is upstreamed in VSCode. The rust extension there (which solely provides said grammar) would need to set appropriate balancedBracketScopes, something like

"balancedBracketScopes": [
                    "punctuation.brackets.angle.rust",
                    "punctuation.brackets.square.rust",
                    "punctuation.brackets.curly.rust",
                    "punctuation.brackets.round.rust",
                    "punctuation.brackets.attribute.rust"
                ]

Ideally the whole thing would work with semantic tokens as thats what rust-analyzer emits but VSCode doesn't allow that, neither does it respect semantic token to textmate token fallback to work with it. So there isn't really anything to do from our side here.

So I just realized, but this does not work for me 🤔 Is there something specific one has to do in VSC to make injected grammars work?

Oh that was a mistake, the feature should've stayed there I think. The test is still wanted.

https://github.com/rust-lang/rust/issues/54910

But that is an allow by default lint, so should we do this?

We should, that lint should be warn by default anyways, but there was some reason as to why some of the 2018 lints are still allowed by default.

Fwiw, it would be pretty easy to make the derive macro work in gc-arena itself by just adding an extern crate self as gc_arena; alias to the crate root of gc-arena.

Though its questionable whether you should use it if you don't have to since that would make gc-arena itself depend on syn.

it might help to destructure result here so that when a new field is added it will error here

how long were you using that rust-analyzer session, over time the memory usage will increase as we don't free analysis related things. So the more code you touch the more of the analysis will be in memory

You cannot fathom how much I hate the rustc workspace.

So the cause of this is https://github.com/rust-lang/rust-analyzer/pull/14935 which fixes some other issues related to the sysroot having been duplicated (for certain reasons). Now that we no longer do this we get a ton of cycles. How does rustc know when to inject the sysroot and when not to on its own workspace? That is basically the problem here, since the library crates depend on a bunch of other crates that have the sysroot injected by r-a again when it shouldn't I suppose

@bors r+

Our diagnostics infra was written with the idea in mind that dianostics reported from macro expansions will only end up in the calling file and as such we never verify that the upmapped ranges belong to the file we calculate the diagnostics for. This assumption is incorrect, include! calls in fact have two macro inputs from differing files, as such, any diagnostic calculated from an included file right now will either report the diagnostic in some random location in the calling file or worse crash the server.

An example crash test case for unresolved_macro_call diagnostic:

    #[test]
    fn include_does_not_break_diagnostics() {
        check_diagnostics(
            r#"
//- minicore: include
//- /lib.rs crate:lib
include!("include-me.rs");
//- /include-me.rs
/// long doc that pushes the diagnostic range beyond the first file's text length
#[err]
mod prim_never {}
"#,
        );
    }

@bors r+

Reverts rust-lang/rust-analyzer#14965

This won't quite work actually given the use of catch_unwind in some of these

@bors r+

the diagnostics task is panicking I think, but without this you can't really tell because the stack trace ends in a generic iterator fold call instead of something specific.

<!-- Troubleshooting guide: https://rust-analyzer.github.io/manual.html#troubleshooting Forum for questions: https://users.rust-lang.org/c/ide/14

Before submitting, please make sure that you're not running into one of these known issues:

1. on-the-fly diagnostics are mostly unimplemented (cargo check diagnostics will be shown when saving a file): #3107

Otherwise please try to provide information which will help us to fix the issue faster. Minimal reproducible examples with few dependencies are especially lovely <3. -->

rust-analyzer version: (eg. output of "rust-analyzer: Show RA Version" command, accessible in VSCode via <kbd>Ctrl/⌘</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd>)

0.3.1533-standalone 0.4.1539-standalone

rustc version: (eg. output of rustc -V)

rustc 1.69.0 rustc 1.70.0

relevant settings: (eg. client settings, or environment variables like CARGO, RUSTC, RUSTUP_HOME or CARGO_HOME)

default by cargo new XXXX

Report Wacky color highlighting caused by declarative macro inside another declarative macro in VS Code.

Expected(?) (before rust-analyzer loaded) result:

Actual result:

Code:

let bol = true;

    // minimal reproduction
    let _ = format!("{}", {
        format!("");
        bol 
    },);

    let _ = format!(
        "{}{}{}",
        // ok
        if bol { "beep" } else { "boop" },
        // broke here
        format!("beep"),
        // broken :(
        if bol {
            "beep"
        } else {
            match bol {
                true => "beep",
                false => "boop",
            }
        }
    );

This is https://github.com/rust-lang/rust-analyzer/issues/14841

No, we want as little changes in the upstream subtree as possible. We are just lacking behind with the syncs atm because of problems we had at our hand. We might be able to sync next week again, then we can merge this.

This will have to wait for the the next subtree sync, that is also the reason why you ran into those weird problems

@bors r+