Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency with derive(Debug) #11947

Closed
rgnkn opened this issue Apr 9, 2022 · 2 comments
Closed

Inconsistency with derive(Debug) #11947

rgnkn opened this issue Apr 9, 2022 · 2 comments

Comments

@rgnkn
Copy link

rgnkn commented Apr 9, 2022

I'm not sure if rust-analyzer is the right place to inform about a annoying inconsistency with some warnings. Please check the following two examples which are essentially the same:

Screenshot from 2022-04-09 16-42-54

Screenshot from 2022-04-09 16-43-22

Both are producing the same output but while the second one leaves rust-analyzer silenced, the first one is full with "debatable" warnings. I would expect the derived output to let the warnings be silenced as with the second example as the field gets indeed read.

If the "intentionally ignored" refers to this behavior: Is there any way to turn this "ignorance" off?

This is no real big issue but it clutters the sources code and I think it might confuse especially beginners. If you think that this should be addressed somewhere else: Please guide me.

BTW: I'm using nightly.

@bjorn3
Copy link
Member

bjorn3 commented Apr 9, 2022

You can use #![allow(dead_code)]. These warnings are produced by rustc not rust-analyzer.

I would expect the derived output to let the warnings be silenced as with the second example as the field gets indeed read.

This used to be the case but was intentionally changed in rust-lang/rust#85200.

Derived implementations of Clone and Debug always trivially read all fields, so "field is never read" dead code warnings are never triggered. Arguably, though, a user most likely will only be interested in whether their code ever reads those fields, which is the behavior I have implemented here.

@rgnkn
Copy link
Author

rgnkn commented Apr 9, 2022

Ok, thanks. So, I will close this issue for rust-analyzer.

FYI:

I know that I could turn off the warning, but I don't want to. In this instance I will just live with those warnings though I think it remains inconsistent even with the rationale in mind that you mentioned; given this rationale I'd expect - from a users point - the warning also on the second example.

@rgnkn rgnkn closed this as completed Apr 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants