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#1148Fixes#1628Fixes#2455Fixes#3023Fixes#3333Fixes#3360
Co-authored-by: Jane Lusby <jlusby42@gmail.com>
Co-authored-by: Philipp Hansch <dev@phansch.net>
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
3355: Lint to remove redundant `clone()`s r=oli-obk a=sinkuu
This PR adds lint `redundant_clone`. It suggests to remove redundant `clone()` that clones a owned value that will be dropped without any usage after that.
Real-world example: https://github.com/rust-lang/rust/compare/7b0735a..sinkuu:redundant_clone2
Co-authored-by: Shotaro Yamada <sinkuu@sinkuu.xyz>
3331: Disable arithmetic lints in constant items r=oli-obk a=pengowen123
Currently this will not catch cases in associated constants. I'm not sure whether checking spans is the best way to solve this issue, but I don't think it will cause any problems.
Fixes#1858
Co-authored-by: Owen Sanchez <pengowen816@gmail.com>
3338: new_ret_no_self false positives r=flip1995 a=JoshMcguigan
~~WORK IN PROGRESS~~
I plan to fix all of the false positives in #3313 in this PR, but I wanted to open it now to start gathering feedback.
In this first commit, I've updated the lint to allow tuple return types as long as `Self` shows up at least once, in any position of the tuple. I believe this is the broadest possible interpretation of what should be allowed for tuple return types, but I would certainly be okay making the lint more strict.
fixes#3313
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3350: Don't emit `new_without_default_derive` if an impl of Default exists regardless of generics r=oli-obk a=pengowen123
Fixes#2226
Co-authored-by: Owen Sanchez <pengowen816@gmail.com>
