Odd rust-analyzer syntax error

[RalfJung]

Right now, rust-analyzer is complaining about the syntax in this function that is totally fine for cargo check:

    fn visit_statement(&mut self, statement: &Statement<'tcx>, location: Location) {
        if let StatementKind::Assign(box (into, _)) = &statement.kind {
            debug!(
                "visit_statement: statement={:?} local={:?} \
                    never_initialized_mut_locals={:?}",
                statement, into.local, self.never_initialized_mut_locals
            );
            self.remove_never_initialized_mut_locals(*into);
        }

        self.super_statement(statement, location);
    }

In the super_statement line, it says

{
	"resource": "/home/r/src/rust/rustc.3/src/librustc_mir/borrow_check/used_muts.rs",
	"owner": "_generated_diagnostic_collection_name_#0",
	"severity": 8,
	"message": "Syntax Error: expected field name or number",
	"source": "rust-analyzer",
	"startLineNumber": 92,
	"startColumn": 14,
	"endLineNumber": 92,
	"endColumn": 14
}
{
	"resource": "/home/r/src/rust/rustc.3/src/librustc_mir/borrow_check/used_muts.rs",
	"owner": "_generated_diagnostic_collection_name_#0",
	"severity": 8,
	"message": "Syntax Error: expected SEMICOLON",
	"source": "rust-analyzer",
	"startLineNumber": 92,
	"startColumn": 14,
	"endLineNumber": 92,
	"endColumn": 14
}

I presume this has something to do with it getting confused while I was typing, and then not properly recovering when I was done typing... the error appeared while I was adding that super_statement line, and it went away after I did "reload window".

[matklad]

Hm, so this looks not like syntax error (the code is fine if I paste it into a new buffer) but rather like an incremental sync problem... Not sure how to debug this though, I am rewriting associated bits rn, so there's a chance that it'll either go away or be swapped with a different error.

cc @lnicola just in case

[cynecx]

incremental sync problem

Just wondering, is there a command to trigger a whole (non-incremental) document synchronization without restarting the lsp server (aka reloading vscode)?

[flodiebold]

I think closing and opening the file should usually do it? (maybe VSCode tries to be smarter though...)

[lnicola]

@RalfJung have you seen this lately?

[RalfJung]

No I have not seen this in a while... but right now, no matter what I do in that file, rust-analyzer doesn't show any kind of syntax error. So I am not sure how I'd even test this.

[mieubrisse]

I've been seeing this erroneous "Expected SEMICOLON" multiple times today - first in #4503 (comment) , and then here:

The red squiggle under ensure in the comment is the same "Expected SEMICOLON" error, and it goes away when I restart Visual Studio.

In my case, I'm transforming Golang code into Rust code, so I'll copy a chunk of Golang code and slowly transform it. It seems that rust-analyzer gets unrecoverably confused when the Golang code gets pasted in until I restart Visual Studio.

[mieubrisse]

If y'all need any debugging data, let me know - I'm getting this over and over and over today:

[bjorn3]

I also saw it a few times with rust-analyzer.rustcSource today. Restarting rust-analyzer fixed it for a moment and then it quickly happened again. Unsetting rust-analyzer.rustcSource fixed it.

[mieubrisse]

Adding that this is happening multiple times per hour for me. Restarting Rust Analyzer inside of VS Code seems to only fix it very temporarily, whereas restarting VS Code itself seems to fix it for longer (though in both cases the problem always recurs).

I used to think that this happens due to Go code being mixed in with Rust code, but I don't think that's the case any more - I've seen rust-analyzer get in the "stuck" state even without any Go code (though I haven't figured out a good repro yet).

If there's any debugging information I can get, please let me know!

[lnicola]

Do you get any panics in the Rust Analyzer output channel then it happens? (Watch out, there's a couple of them)

[mieubrisse]

Unfortunately I worked through all the translation that I needed to do, so I'm no longer in the situation where I'm seeing this. I'll post back here if it recurs though - how can I view the panics in the Rust Analyzer output channel?

[lnicola]

how can I view the panics in the Rust Analyzer output channel?

You open the channel and they'll be there if any of them happened.

[mieubrisse]

Thanks for the quick response @lnicola ! I have to beg ignorance here; I'm not sure how to open the channel - I've only just started using VS Code, searching its help for "channel" didn't turn up anything, and Googling for "rust analyzer output channel" turned up only this guy.

[lnicola]

F1, Show Output Window (or something like that), then use the list on the top-right of the output window to switch channels.

rust-analyzer has three of them, panics show up only in one of those. They're created lazily, so if you don't have three, they're empty.

[mieubrisse]

Got it, thanks! Next time I see this I'll pull that up and copy-paste the output here

…

On Sun, Feb 21, 2021 at 2:01 PM Laurențiu Nicola ***@***.***> wrote: F1, Show Output Window (or something like that), then use the list on the top-right to switch channels. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4829 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIW3KNK6ACUUIJ3XS2EQ4DTAFJ73ANCNFSM4N2EJT6Q> .

[mieubrisse]

I had this happen again, where rust-analyzer was complaining about a missing semicolon even though the Rust code was fine. I deleted the line I thought caused it, cleared the rust-analyzer output, and re-pasted the line that caused the missing semicolon but no rust-analyzer output popped up. I moved to a different section of the code, and rust-analyzer was complaining about a similarly-strange error:

Simply by closing and reopening VS code, the errors fixed themselves:

There might have been something in the rust-analyzer output before I cleared it, but I'd taken a brief scroll through it and didn't see anything.

Of note: I wasn't working with any Go code this time; it was purely Rust code.

[mieubrisse]

Just had it happen again, when adding a field to a struct. On recollection, I think the previous comment's instance also had to do with adding a field to a struct.

Here's the code:

Here's the error:

Full rust-analyzer output:

INFO [3/3/2021, 2:14:40 PM]: Extension version: 0.2.505
INFO [3/3/2021, 2:14:40 PM]: Using configuration {
  cargoRunner: null,
  runnableEnv: null,
  inlayHints: {
    enable: true,
    chainingHints: true,
    maxLength: null,
    parameterHints: false,
    typeHints: false
  },
  updates: { channel: 'stable', askBeforeDownload: true },
  server: { path: null, extraEnv: null },
  trace: { server: 'off', extension: false },
  debug: {
    engine: 'auto',
    sourceFileMap: {
      '/rustc/<id>': '${env:USERPROFILE}/.rustup/toolchains/<toolchain-id>/lib/rustlib/src/rust'
    },
    openDebugPane: false,
    engineSettings: {}
  },
  assist: { importMergeBehavior: 'full', importPrefix: 'plain' },
  callInfo: { full: true },
  cargo: {
    autoreload: true,
    allFeatures: false,
    features: [],
    loadOutDirsFromCheck: false,
    noDefaultFeatures: false,
    target: null,
    noSysroot: false
  },
  checkOnSave: {
    enable: true,
    allFeatures: null,
    allTargets: true,
    command: 'check',
    noDefaultFeatures: null,
    target: null,
    extraArgs: [],
    features: null,
    overrideCommand: null
  },
  completion: {
    addCallArgumentSnippets: true,
    addCallParenthesis: true,
    postfix: { enable: true },
    autoimport: { enable: true }
  },
  diagnostics: {
    enable: true,
    enableExperimental: true,
    disabled: [],
    warningsAsHint: [],
    warningsAsInfo: []
  },
  files: { watcher: 'client', excludeDirs: [] },
  hoverActions: {
    debug: true,
    enable: true,
    gotoTypeDef: true,
    implementations: true,
    run: true,
    linksInHover: true
  },
  lens: {
    debug: true,
    enable: true,
    implementations: true,
    run: true,
    methodReferences: false,
    references: false
  },
  linkedProjects: [],
  lruCapacity: null,
  notifications: { cargoTomlNotFound: true },
  procMacro: { enable: false, server: null },
  runnables: { overrideCargo: null, cargoExtraArgs: [] },
  rustcSource: null,
  rustfmt: { extraArgs: [], overrideCommand: null }
}
INFO [3/3/2021, 2:14:40 PM]: PersistentState: {
  lastCheck: undefined,
  releaseId: undefined,
  serverVersion: '0.2.505'
}
INFO [3/3/2021, 2:14:40 PM]: Using server binary at /Users/zerix/Library/Application Support/Code/User/globalStorage/matklad.rust-analyzer/rust-analyzer-x86_64-apple-darwin

and the exact same code, now without errors, after restarting:

[lnicola]

Do you have anything in the other Output channels?

If you can find a way to reproduce this, it would be awesome.

[mieubrisse]

I unfortunately haven't found a way yet - I'm hoping that if I collect enough data on this issue, a pattern will eventually start to emerge. Next time I see it I'll check the other output channels too

[lnicola]

Do you have non-Latin characters in your code?

You could also try setting RA_DISABLE_INCREMENTAL_SYNC=0 (I think that's how it's called) to exclude a possible cause of bugs. It's an environment variable, I think there's a preference for extra ones to set for the server.

[mieubrisse]

Ah apologies @lnicola , I missed your response! Nope, no non-Latin characters in the code. I've just hit the bug again on a very innocuous change:

The only change I made is a) change the response type of the function from Result<i32> to Result<(i32, Vec<u8>)> and b) change the return from Ok(resp.exit_code) to Ok((resp.exit_code, resp.log_output)). I'm starting to think that the actual change itself is a red herring, given how different the changes are that have triggered this issue - I'm suspecting now something more like memory profile, or maybe that incremental sync like you mentioned.

This is the entire Rust Analyzer channel output, and it does have panics (though I've had VS Code open for several days, so I'm not sure how far back this goes):

rust-analyzer-output.log

While researching how to set the RA_DISABLE_INCREMENTAL_SYNC environment variable, I also found a couple diagnostic things that I'll include here as well:

Rust Analyzer Version:

rust-analyzer version: 2021-03-01 (5df3ee8)

Rust Analyzer Status:

workspaces:
146 packages loaded

analysis:
3323 (36mb) files
0 (0b) index symbols
2502 trees, 128 retained
25772 trees, 128 retained (macros)
0b total

counts:
all counts are zero


requests:
  621 textDocument/codeLens               0ms
  622 textDocument/hover                  0ms
* 612 textDocument/codeLens               0ms
  613 textDocument/codeLens               0ms
  614 textDocument/codeLens               0ms
  615 textDocument/codeLens               0ms
  616 textDocument/codeLens               0ms
  617 textDocument/codeLens               0ms
  618 textDocument/codeLens               0ms
  619 textDocument/codeLens               0m

I've also now added the following to my settings.json:

    "rust-analyzer.server.extraEnv": {
        "RA_DISABLE_INCREMENTAL_SYNC": "0",
        "RA_LOG": "info",
    }

This required reloading rust-analyzer, which made the erroneous error go away. Hopefully the above is useful!

[lnicola]

@mieubrisse no news here unfortunately, but the env variable name is actually RA_NO_INCREMENTAL_SYNC, not RA_DISABLE_INCREMENTAL_SYNC (sorry for that, I was on my phone), so setting the latter should have had no effect.

[lnicola]

Your log also has interesting tidbits like:

thread '<unnamed>' panicked at 'Bad offset: range 0..1680 offset 15194', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/rowan-0.12.6/src/cursor.rs:430:9
stack backtrace:
   0: _rust_begin_unwind
   1: std::panicking::begin_panic_fmt
   2: rowan::cursor::SyntaxNode::token_at_offset
   3: syntax::algo::ancestors_at_offset
   4: syntax::algo::find_node_at_offset
   5: ide::references::find_all_refs
   6: std::panicking::try
   7: ide::Analysis::find_all_refs
   8: rust_analyzer::handlers::handle_document_highlight
   9: <F as threadpool::FnBox>::call_box
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread '<unnamed>' panicked at 'overflow depth reached', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/chalk-recursive-0.58.0/src/stack.rs:51:13
stack backtrace:
   0: std::panicking::begin_panic
   1: chalk_recursive::stack::Stack::push
   2: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
   3: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
   4: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
   5: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
   6: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
   7: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
   8: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
   9: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  10: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  11: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  12: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  13: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  14: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  15: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  16: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  17: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  18: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  19: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  20: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  21: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  22: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  23: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  24: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  25: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  26: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  27: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  28: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  29: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  30: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  31: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  32: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  33: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  34: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  35: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  36: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  37: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  38: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  39: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  40: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  41: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  42: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  43: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  44: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  45: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  46: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  47: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  48: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  49: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  50: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  51: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  52: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  53: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  54: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  55: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  56: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  57: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  58: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  59: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  60: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  61: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  62: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  63: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  64: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  65: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  66: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  67: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  68: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  69: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  70: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  71: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  72: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  73: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  74: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  75: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  76: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  77: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  78: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  79: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  80: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  81: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  82: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  83: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  84: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  85: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  86: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
  87: chalk_recursive::fulfill::Fulfill<I,Solver>::prove
  88: chalk_recursive::fulfill::Fulfill<I,Solver>::solve
  89: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
  90: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal

where the large difference between the file size (1681 bytes) and the requested offset (15194) make it sound like we are trying to look into the wrong file. That can happen with macro-expansion bugs.

[jonas-schievink]

In #11861, I've added a "view file text" command that displays the server's view of the file. In case anyone sees a desync like this happen again, please run that command and post the difference, maybe that tells us a clue about what's wrong.

[Veykril]

I'll close this, it hasn't happened for anyone in a long time, if it re-appears we can re-open this