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.
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.
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.
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.
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.