Request textDocument/semanticTokens/full failed on nightly and May 9 release

[msdrigg]

In the latest release, Rust Analyzer has become unusable for one of the projects I am working on.

I am seeing repeated alerts saying

Request textDocument/semanticTokens/full/delta failed.
Request textDocument/definition failed.
Request textDocument/inlayHint failed.
Request textDocument/hover failed.

These all appear to be related to a panic at crates/mbe/src/syntax_bridge.rs:275:29

Verbose Log

Verbose Logs

Panic context:

>
version: 94fa8a6 2022-05-12 nightly

request: textDocument/inlayHint InlayHintParams {
    work_done_progress_params: WorkDoneProgressParams {
        work_done_token: None,
    },
    text_document: TextDocumentIdentifier {
        uri: Url {
            scheme: "file",
            cannot_be_a_base: false,
            username: "",
            password: None,
            host: None,
            port: None,
            path: "/home/msd/Github/rustls/crates/signals2/src/lib.rs",
            query: None,
            fragment: None,
        },
    },
    range: Range {
        start: Position {
            line: 0,
            character: 0,
        },
        end: Position {
            line: 21,
            character: 0,
        },
    },
}

thread '<unnamed>' panicked at 'assertion failed: (left == right)
left: DOT,
right: FLOAT_NUMBER_PART', crates/mbe/src/syntax_bridge.rs:275:29
stack backtrace:

   0: rust_begin_unwind
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:143:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
   4: mbe::syntax_bridge::syntax_node_to_token_tree_with_modifications
   5: hir_expand::db::macro_arg
   6: <hir_expand::db::MacroExpandQuery as salsa::plumbing::QueryFunction>::execute
   7: salsa::runtime::Runtime::execute_query_implementation
   8: salsa::derived::slot::Slot<Q,MP>::read_upgrade
   9: salsa::derived::slot::Slot<Q,MP>::read
  10: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  11: salsa::QueryTable<Q>::get
  12: <DB as hir_expand::db::AstDatabase>::macro_expand
  13: salsa::runtime::Runtime::execute_query_implementation
  14: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  15: salsa::derived::slot::Slot<Q,MP>::read
  16: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  17: salsa::QueryTable<Q>::get
  18: <DB as hir_expand::db::AstDatabase>::macro_expand_error
  19: hir_def::nameres::collector::DefCollector::collect_macro_expansion
  20: hir_def::nameres::collector::collect_defs
  21: hir_def::nameres::DefMap::block_def_map_query
  22: salsa::runtime::Runtime::execute_query_implementation
  23: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  24: salsa::derived::slot::Slot<Q,MP>::read
  25: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  26: salsa::QueryTable<Q>::get
  27: <DB as hir_def::db::DefDatabase>::block_def_map
  28: hir_def::body::lower::ExprCollector::collect_block
  29: hir_def::body::lower::ExprCollector::maybe_collect_expr
  30: hir_def::body::lower::ExprCollector::collect_block
  31: hir_def::body::lower::ExprCollector::maybe_collect_expr
  32: hir_def::body::lower::ExprCollector::collect_stmt::{{closure}}
  33: hir_def::body::lower::ExprCollector::collect_stmt
  34: hir_def::body::lower::ExprCollector::collect_stmt::{{closure}}
  35: hir_def::body::lower::ExprCollector::collect_stmt
  36: hir_def::body::lower::ExprCollector::collect_block
  37: hir_def::body::lower::ExprCollector::maybe_collect_expr
  38: hir_def::body::Body::body_with_source_map_query
  39: salsa::runtime::Runtime::execute_query_implementation
  40: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  41: salsa::derived::slot::Slot<Q,MP>::read
  42: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  43: salsa::QueryTable<Q>::get
  44: <DB as hir_def::db::DefDatabase>::body_with_source_map
  45: hir::source_analyzer::SourceAnalyzer::new_for_body_no_infer
  46: hir::semantics::SemanticsImpl::analyze_impl
  47: hir::semantics::SemanticsImpl::scope
  48: ide::inlay_hints::hints
  49: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
  50: ide::inlay_hints::inlay_hints
  51: std::panicking::try
  52: rust_analyzer::handlers::handle_inlay_hints
  53: std::panicking::try
  54: <F as threadpool::FnBox>::call_box
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[Error - 6:23:11 PM] Request textDocument/inlayHint failed.
Message: request handler panicked: assertion failed: (left == right)
left: DOT,
right: FLOAT_NUMBER_PART
Code: -32603

Minimum Reproducible Example

(No dependencies. Only one file)

// lib.rs
macro_rules! assert_about_eq {
    ($a:expr, $b:expr, $eps:expr) => {
        let eps = $eps;
        assert!(
            true,
            "assertion failed: `(left !== right)` \
             (left: `{:?}`, right: `{:?}`, epsilon: `{:?}`)",
            $a, $b, eps
        );
    };
}

pub fn func_good() {
    let val = 20.2;
    assert_about_eq!(val, val, val);
}

pub fn func_bad() {
    let val = 20.2;
    assert_about_eq!(val, 20.2, val);
}

If you delete func_bad, rust-analyzer works as expected

Additionally, if you replace

        assert!(
            true,
            "assertion failed: `(left !== right)` \
             (left: `{:?}`, right: `{:?}`, epsilon: `{:?}`)",
            $a, $b, eps
        );

with

        println!(
            "assertion failed: `(left !== right)` \
             (left: `{:?}`, right: `{:?}`, epsilon: `{:?}`)",
            $a, $b, eps
        );

rust-analyzer works as expected

Additional Notes

I tested on nightly today and I still see this issue. The issue is also present in the May 9 release, but it is not present in the May 2 release.

This may be related to the closed issue #12211 (comment), but I don't know enough to say whether or not these are the same. I will test on nightly again once a nightly build is available with this patch.

If I can reproduce after testing with nightly tonight or tomorrow, I will @ matklad, and say that this is an urgent issue, but I don't want to escalate this until I am sure it hasn't already been fixed.

[msdrigg]

@Veykril. I just downloaded the binary I could find in this github actions from last night (https://github.com/rust-lang/rust-analyzer/actions/runs/2316746521). The publish failed, but I could still download and install the binary from the zip attachments.

I can verify that this is still an issue. I see you unassigned matklad, so I won't tag him, but I wanted to confirm to someone that this issue still exists and was not resloved by #12211

The only thing I see that changed is that instead of getting the panic at crates/mbe/src/syntax_bridge.rs:275:29, I am now getting it at crates/mbe/src/syntax_bridge.rs:277:29

Looking at the exact commit, it appears that we are seeing this panic.

rust-analyzer/crates/mbe/src/syntax_bridge.rs

Line 277 in 0c881e8

assert_eq!(tail.kind(conv), FLOAT_NUMBER_PART);

[Veykril]

Ye that is what the Broken Window label is for here

[jonas-schievink]

The PR that caused this was reverted in #12241