Faint code in VS Code with rust-analyzer plugin enabled

So here's an odd one... I woke up this morning, open VS Code to work on my Rust project and for the first time every, my code appears to be very faint. It looks like this:

This is how all of my Rust code appears in VS Code. Any other type of code appears fine. I'm using VS Code on an M1 Mac and I have rust_analyzer installed and enabled. I think that it must have something to do with rust_analyzer because if I disable it, it looks fine. That said, this is a new behaviour that just started this morning. If it persists, I think I'll need to disable the plugin because it is frankly really hard on the eyes. Any suggestions as to how to fix this?

2 Likes

I could be wrong but my guess is that this is caused by what's called "semantic highlighting". That is it uses different colours depending on the type. These colours should be set by the theme you're using.

You can try turning it off in the settings and see if it makes a difference.

@chrisd Thanks for your reply. I have actually tried switching the syntax highlight to different themes in VS Code and it persists. Furthermore, it isn't fainter for portions of my code (e.g. a specific type) but rather for the entirety of my Rust codebase. Also, my Nim code and Python Code look absolutely fine in the text editor. It does appear to have something to do with the rust-analyzer plugin though since it goes away when I disable. So to does a whole lot of the functionality that I have come to enjoy though, and so this is a real problem for me. I've Googled 'rust-analyzer faint code' but haven't had anything useful pop up. I was hoping that someone here might have experience with this problem. It's so bad that I'm considering using a different IDE, like InteliJ IDEA instead, but I really don't want to switch. I'm about six months overdue for my next eye exam and new glasses due to the pandemic and this is really adding to the strain!

At the top of your crate [main|lib].rs, do you have something like :

#![cfg(unix)]

or :

#![cfg(feature = "xxx")]

Where xxx isn't part of the enabled defaults in Cargo.toml ? That's a guess, but maybe ?

Unrelated edit, eye strain advice : zoom every website to 150-200% (this one is at 160%), use big font size in your editor (above 20p at least), I have perfect eyesight (LASIK, not innate) but I have done that for almost two years now, neck pains have considerably decreased.

2 Likes

@jRimbault No, I don't have any such configuration at the top of my file. This is truly an odd one. I did update to the new version of Rust this morning. Perhaps that has resulted in this change of behaviour. Anyhow, I've just turned off rust-analyzer now and hope that whatever caused this behaviour will soon be resolved. I can't imagine that faint code is a feature. As for your suggestion, thanks for the advice. It's true that small fonts on the web are often the result of my eye fatigue at the end of the day. I will do this. I remember when I was young my parents saying, 'just you wait until you hit 40 and you won't be able to see anything.' Well now I'm saying that to my son!

1 Like

This is very likely the new unlinked-file diagnostic, which grays out files that are not part of the module hierarchy. If so, you can disable it by adding "unlinked-file" to the "rust-analyzer.diagnostics.disabled" setting; but note that this means that rust-analyzer is already basically not working at all in your code. Is there anything abnormal about your project structure? Is the project public?

(BTW, feel free to report something like this as an issue in the rust-analyzer repository.)

1 Like

I don't think that there is anything unusual about my project structure, but you are right that I am seeing the notice that the file is an unlinked-file, which I thought was odd. The code isn't open currently, but the structure of the project is simply:

evaluate_training_sites
|-- src
|-- |-- main.rs

Which I created using the cargo init command. My Cargo.toml file contains the following dependencies:

chrono = "0.4.15"
hex = "0.4.3"
sha2 = "0.9.3"
whitebox_common = { path = "../../whitebox-tools/whitebox-common" }
whitebox_raster = { path = "../../whitebox-tools/whitebox-raster" }
whitebox_vector = { path = "../../whitebox-tools/whitebox-vector" }

Those 'whitebox' dependences are local projects. Perhaps that has something to do with it?

Hmm. Can you reproduce this with a fresh project?

It's happening to me as well. I have the default "main" crate which builds the binary (root folder with cargo.toml and src folder).

I have two subcrates from the main folder. One of the subcrates is a mainlib, where the main crate depends on. The other is a library crate which will be built to a shared lib for android, which the main crate doesn't need (main crate is Windows executable, library crate is android ndk library; both depend on mainlib for functions)

The library subcrate is showing this "unlinked" error, along with "!!MISSING: Command!!". All intellisense is gone and pretty much put me at a standstill since I relied on those and error highlighting.

This same basic structure I have defined above can be reproduced with a new project.

Yes, this describes my experience too. I have had to disable rust-analyzer, which is a real shame because there is so much lost in doing so. I hope it gets resolved soon. Do you also get the incredibly faint text?

Yes, the whole file is faint, says "!!MISSING: command!!", and intellisense is gone on all files, including build.rs

From my own testing, I think that re-organizing the project into a workspace mode fixes it. But you have to include all modules as members, otherwise that one will show up as "unlinked" again. This feature feels kind of unintuitive since it seems to disable the ability to even develop.

And what's worse is that even going to the fallback of the official Rust extension isn't a solution since intellisense won't work on that one either.

I'm unsure as of this moment whether this module organization can still achieve separate what's needed, but it probably can. Since I have different build targets, there's no other way to do this except invoke cargo build twice anyways.

This is already fixed, we now only emit a hint-level diagnostic without the "unused" tag. You might need to wait for the next release.

Note that the unlinked-file diagnostic does not impact rust-analyzer functionality, it already wasn't working properly before, just without the diagnostic.

3 Likes

That's great to hear!

I discovered why intellisense is not working. It's not an error in my file. When I remove this line #![cfg(target_os="android")] it works. Must be related somehow to what was said above, but since this isn't a feature, not sure how to "enable" it so intellisense works

I have this issue too, on both my notebook and PC, both with fresh setups (just got started learning Rust). The code faints both with light and dark themes, I tried OneDark Pro, Light+ and Dark+. The code doesn't faint out at first, only does so when rust-analyzer finishes indexing the project.

edit 1: For me the bug occurs in the two newest versions, 0.2.538 and 0.2.529.
edit 2: Seems to be fixed in git, we'll just have to wait for the next release.

I think in my case the unlinked-file diagnostic might just be uncovering an existing issue with rust-analyzer's module hierarchy system? Is it possible that RA's internal API is interfering here?

I have a project with a module parsemath and within it, a few additional modules including one named tokenizer.rs. I have a 'pub mod tokenizer;' in the mod.rs file, but rust-analyzer thinks it's not in the module tree.

If I rename the file to anything else (and refactor) RA is then able to parse it. When I rename it back to tokenizer.rs (and refactor) RA again stops thinking it's part of the module tree.

I am also very new to rust, but this code does build. Here is the repo:

BeldrothTheGold/rust_mathparser: Example program from chapter two of Practical System Programming for Rust Developers (github.com)

Hmm @BeldrothTheGold, I'm not able to reproduce this with your test project. Does this persist even if you restart VSCode? It's a bit suspicious that it's suggesting to insert mod Tokenizer with capital T. Are you using Windows? Maybe it's related to file name case insensitivity...

Hey @fdiebold, that's interesting. I am using MacOS Catalina. Yes, it is reproducible between restarts of VSCode.

@fdiebold sorry, you know what, no it is not persisting between applications restarts. I am also newish to Mac and sometimes forget that closing the window does not quit the application.

I apologize. It must have been some strange state the tool got in after upgrading.