Strange situation: vscode rust-analyser gives different results to cargo build (rustc)

I am ending up with strange (not making sense) errors while editing the source files in vscode, yet when I build the project using cargo build no errors or warnings are produced, and end up with a binary, which runs without producing a runtime errors.

Below is the weird incorrect error, cause the method does instead exists (even displayed in the tooltip):

===== start ============
error[E0599]: no method named language_tag_registry found for reference &Message<ProviderSqlite3> in the current scope
--> crates/gui/src/app.rs:333:41
|
333 | let language_registry = message.language_tag_registry();
| ^^^^^^^^^^^^^^^^^^^^^ private field, not a method
===== end ============

The tool tip message:
===== start ============
no method named language_tag_registry found for reference &Message<ProviderSqlite3> in the current scope
private field, not a methodrustcClick for full compiler diagnostic

i18n_message::message::Message

pub fn language_tag_registry(&self) -> &RefCount


Obtain the language tag registry for the Message instance.

Go to Rc | LanguageTagRegistry
===== end ============

I am completely baffled by the rust-analyser error, when cargo build works correctly.

Unfortunately, most IDEs don't use the compiler itself for analyzing the code. I believe this is also the case with rust-analyzer.

In this kind of situation, the compiler is right, and the IDE is wrong. (With overwhelming probability, anyway.) When in doubt, run cargo check.

R-A does, in fact, use cargo check (or clippy, if configured) for it's diagnostics.
But for type hints and completion suggestions it has to use it's own trait solver, which some times produces different results.
Said trait solver, chalk, IIRC, is supposed to be merged into rustc at some poit.

Unless the code and the current compiler both have a bug, this can't be the case. Rust's backward compatibility guarantees mean that switching to a new trait solver implementation can't just suddenly start breaking already compiling (correct) code.

If the current compiler is right, and the code is bug-free and should rightfully compile, then RA is simply wrong about rejecting it.

Chalk is discontinued[1] and the next generation solver is called "new solver" or the like in PRs, etc. Tracking issue.

(No idea how that relates to whatever R-A uses.)


  1. at least as far as being a target for integration with rustc ↩︎

1 Like

rust-analyzer does in fact both run cargo check to produce diagnostics and perform its own analyses. The error in the OP comes from rustc (as it says "private field, not a methodrustc"), so this has to be caused by some configuration difference (environment variables, toolchain version, etc.) or maybe an incremental compilation bug.

So this could be a result of cargo.toml features are not being picked up by rust-analyser (yep cargo check also gives same results), yet cargo build handles the features correctly and builds a working binary.

Perhaps there is a bug in cargo check component.

I believe RA by default runs cargo check with --all-targets, is the offending code possibly in a target which isn't being built by the command line without that switch?

I ran cargo check as is from console outside of vscode, and it yields the same result as vscode rust-analyser, confirming that rust-analyser does indeed executes cargo check, though unsure if other options are passed.

Yet when I ran cargo build as is from the console, it builds binary without any errors or warnings.

So there is a difference in output between cargo check (fails) and cargo build (succeeds).

If I understand correctly cargo check supposed to run rustc with various options to only parse the source code for warnings and error without producing any byte code objects. While cargo build instructs rustc to produce a resultant binary provided there are no errors.

Seems like it may well be an instance of:

There is also an older closed bug that seems like it has useful/relevant info perhaps:

Reading the newest issue of May 2023, it does seems to be a caching issue, where cargo check is using stale cache, while cargo build rebuilds dependencies that have been updated.

Has occurred again the issue with vscode rust-analyser reporting error with incorrect arguments, yet tooltip shows method with correct method declaration. Ran cargo check and it reports the same error. The dependency library was updated with a new method declaration by adding another argument, which the tooltip displays.

Running cargo build it builds without error and application runs.

Definitely a caching issue, where the cache is not detecting change in dependency and updating with the new source code, while the tooltip component updates its data.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.