-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
dead_code lint highlights too much on functions with multi-line signatures #63064
Comments
I've seen this as well. It's been years since I hacked on the compiler, so I'll claim this as a bug to fix so as to refresh my memory of what's where. :) |
There's a method
With that, most of the places where we are calling
The reason I haven't pushed for that change is because in some cases the extra information from the other lines is useful to give context, but for errors like this one we just need to identify the function and nothing more. |
@estebank, thanks for explaining. This would be in line with what I'd already figured. 🙂 By the way, that function assumes that items would have a leading |
Oh, this has been reported before: #58729. |
Closing as duplicate of #58729 |
Use ident.span instead of def_span in dead-code pass Hello! First time contributor! :) This should fix rust-lang#58729. According to @estebank in the duplicate rust-lang#63064, def_span scans forward on the line until it finds a {, and if it can't find one, falls back to the span for the whole item. This was apparently written before the identifier span was explicitly tracked on each node. This means that if an unused function signature spans multiple lines, the entire function (potentially hundreds of lines) gets flagged as dead code. This could, for example, cause IDEs to add error squiggly's to the whole function. By using the span from the ident instead, we narrow the scope of this in most cases. In a wider sense, it's probably safe to use ident.span instead of def_span in most locations throughout the whole code base, but since this is my first contribution, I kept it small. Some interesting points that came up while I was working on this: - I reorganized the tests a bit to bring some of the dead code ones all into the same location - A few tests were for things unrelated to dead code (like the path-lookahead for parens), so I added #![allow(dead_code)] and cleaned up the stderr file to reduce noise in the future - The same fix doesn't apply to const and static declarations. I tried adding these cases to the match expression, but that created a much wider change to tests and error messages, so I left it off until I could get some code review to validate the approach.
Use ident.span instead of def_span in dead-code pass Hello! First time contributor! :) This should fix rust-lang#58729. According to @estebank in the duplicate rust-lang#63064, def_span scans forward on the line until it finds a {, and if it can't find one, falls back to the span for the whole item. This was apparently written before the identifier span was explicitly tracked on each node. This means that if an unused function signature spans multiple lines, the entire function (potentially hundreds of lines) gets flagged as dead code. This could, for example, cause IDEs to add error squiggly's to the whole function. By using the span from the ident instead, we narrow the scope of this in most cases. In a wider sense, it's probably safe to use ident.span instead of def_span in most locations throughout the whole code base, but since this is my first contribution, I kept it small. Some interesting points that came up while I was working on this: - I reorganized the tests a bit to bring some of the dead code ones all into the same location - A few tests were for things unrelated to dead code (like the path-lookahead for parens), so I added #![allow(dead_code)] and cleaned up the stderr file to reduce noise in the future - The same fix doesn't apply to const and static declarations. I tried adding these cases to the match expression, but that created a much wider change to tests and error messages, so I left it off until I could get some code review to validate the approach.
Use ident.span instead of def_span in dead-code pass Hello! First time contributor! :) This should fix #58729. According to @estebank in the duplicate #63064, def_span scans forward on the line until it finds a {, and if it can't find one, falls back to the span for the whole item. This was apparently written before the identifier span was explicitly tracked on each node. This means that if an unused function signature spans multiple lines, the entire function (potentially hundreds of lines) gets flagged as dead code. This could, for example, cause IDEs to add error squiggly's to the whole function. By using the span from the ident instead, we narrow the scope of this in most cases. In a wider sense, it's probably safe to use ident.span instead of def_span in most locations throughout the whole code base, but since this is my first contribution, I kept it small. Some interesting points that came up while I was working on this: - I reorganized the tests a bit to bring some of the dead code ones all into the same location - A few tests were for things unrelated to dead code (like the path-lookahead for parens), so I added #![allow(dead_code)] and cleaned up the stderr file to reduce noise in the future - The same fix doesn't apply to const and static declarations. I tried adding these cases to the match expression, but that created a much wider change to tests and error messages, so I left it off until I could get some code review to validate the approach.
With the following example code:
(Playground)
The compiler produces these warnings:
Notice that for
fn unused
andfn unused2
,dead_code
is reported on only the first line signature of the function, however forfn unused3
dead_code
is reported on the whole function from start to finish.This is mostly annoying when writing new functions in an editor like vscode that rls will cause the whole function to be orange-wavy-underlined, making a huge distraction.
The text was updated successfully, but these errors were encountered: