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.
phansch
changed the title
phansch
changed the title
phansch
changed the title
|
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