Don't expand macros in some suggestions #3366
Conversation
@@ -72,7 +72,12 @@ impl<'a, 'tcx> LateLintPass<'a, 'tcx> for IdentityConversion { | |||
let a = cx.tables.expr_ty(e); | |||
let b = cx.tables.expr_ty(&args[0]); | |||
if same_tys(cx, a, b) { | |||
let sugg = snippet(cx, args[0].span, "<expr>").into_owned(); | |||
let sugg = if in_macro(args[0].span) { | |||
snippet(cx, args[0].span.source_callsite(), "<expr>").into_owned() |
oli-obk
Oct 27, 2018
Collaborator
Can't we unconditionally call the source callsite methods? if so, can we move it into the snippet function so all lints benefit from it?
Can't we unconditionally call the source callsite methods? if so, can we move it into the snippet function so all lints benefit from it?
phansch
Oct 27, 2018
Author
Member
Yea, I was thinking that this is probably becoming a recurring pattern. I will give it a try!
Yea, I was thinking that this is probably becoming a recurring pattern. I will give it a try!
phansch
Oct 27, 2018
Author
Member
One problem occurs when span.source_callsite()
is called on a format!
argument. This happens in useless_format
lint (and a few other lints):
Unconditionally calling source_callsite
will result in the wrong suggestion because the source_callsite
exists and is the format!
macro in this case:
help: consider using .to_string(): `format!("foo");.to_string()`
I think it still makes sense to have a separate snippet_with_macro_callsite
function for the other cases, though.
One problem occurs when span.source_callsite()
is called on a format!
argument. This happens in useless_format
lint (and a few other lints):
Unconditionally calling source_callsite
will result in the wrong suggestion because the source_callsite
exists and is the format!
macro in this case:
help: consider using .to_string(): `format!("foo");.to_string()`
I think it still makes sense to have a separate snippet_with_macro_callsite
function for the other cases, though.
oli-obk
Oct 27, 2018
Collaborator
Makes sense. This generally only works if the entire situation is outside a macro, but most of our lints are skipping those situations via in_macro
on the full span anyway.
Makes sense. This generally only works if the entire situation is outside a macro, but most of our lints are skipping those situations via in_macro
on the full span anyway.
I added a separate function called I will also go through all the other issues and try to find more cases that can be fixed easily. edit: Ok, I can't find any more issues that will be fixed by this. |
bors r+ |
Build failed |
bors r=oli-obk |
3217: Fix string_lit_as_bytes lint for macros r=phansch a=yaahallo Prior to this change, string_lit_as_bytes would trigger for constructs like `include_str!("filename").as_bytes()` and would recommend fixing it by rewriting as `binclude_str!("filename")`. This change updates the lint to act as an EarlyLintPass lint. It then differentiates between string literals and macros that have bytes yielding alternatives. Closes #3205 3366: Don't expand macros in some suggestions r=oli-obk a=phansch Fixes #1148 Fixes #1628 Fixes #2455 Fixes #3023 Fixes #3333 Fixes #3360 Co-authored-by: Jane Lusby <jlusby42@gmail.com> Co-authored-by: Philipp Hansch <dev@phansch.net>
Fixes #1148
Fixes #1628
Fixes #2455
Fixes #3023
Fixes #3333
Fixes #3360