This test doesn't reproduce the ICE since it only happens, when the macro is defined in another file.
Currently we can't add tests with multiple files AFAIK
Also using the auxiliary folder didn't help
Add a lint to warn on `T: Drop` bounds
**What it does:** Checks for generics with `std::ops::Drop` as bounds.
**Why is this bad?** `Drop` bounds do not really accomplish anything.
A type may have compiler-generated drop glue without implementing the
`Drop` trait itself. The `Drop` trait also only has one method,
`Drop::drop`, and that function is by fiat not callable in user code.
So there is really no use case for using `Drop` in trait bounds.
**Known problems:** None.
**Example:**
```rust
fn foo<T: Drop>() {}
```
Fixes#3773
Both regular strings and raw strings can contain literal newlines. This commit
extends the lint to also warn about terminating strings with these.
Behaviour handling for raw strings is also moved into `check_newlines` by
passing in the `is_raw` boolean from `check_tts` as
[suggested](https://github.com/rust-lang/rust-clippy/pull/3781#pullrequestreview-204663732)
Literal `\n` characters (not a newline) in a `r"raw"` string should not
fail the lint.
This affects both write_with_newline and print_with_newline, so it is added in
both places.
I also copied a missing test case from write_with_newline over to
print_with_newline and added a note that one of those tests is supposed to
fail.
**What it does:** Checks for generics with `std::ops::Drop` as bounds.
**Why is this bad?** `Drop` bounds do not really accomplish anything.
A type may have compiler-generated drop glue without implementing the
`Drop` trait itself. The `Drop` trait also only has one method,
`Drop::drop`, and that function is by fiat not callable in user code.
So there is really no use case for using `Drop` in trait bounds.
**Known problems:** None.
**Example:**
```rust
fn foo<T: Drop>() {}
```
Fix ICE in needless_pass_by_value lint
If I understand it correctly, we were first creating a type with a
`RegionKind::ReErased` region and then deleted it again in
`util::implements_trait` with:
cx.tcx.erase_regions(&ty);
causing the type query to fail.
It looks like using `ReEmpty` works around that deletion.
Fixes#3144
Macro check for assertion_on_constants lint
The `assertion_on_constants` lint currently has following output for this code [Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6f2c9df6fc50baf847212d3b5136ee97):
```rust
macro_rules! assert_const {
($len:expr) => {
assert!($len > 0);
}
}
fn main() {
assert_const!(3);
assert_const!(-1);
}
```
```
warning: assert!(const: true) will be optimized out by the compiler
--> src/main.rs:3:9
|
3 | assert!($len > 0);
| ^^^^^^^^^^^^^^^^^^
...
8 | assert_const!(3);
| ---------------- in this macro invocation
|
= note: #[warn(clippy::assertions_on_constants)] on by default
= help: remove it
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#assertions_on_constants
warning: assert!(const: false) should probably be replaced
--> src/main.rs:3:9
|
3 | assert!($len > 0);
| ^^^^^^^^^^^^^^^^^^
...
9 | assert_const!(-1);
| ----------------- in this macro invocation
|
= help: use panic!() or unreachable!()
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#assertions_on_constants
```
This is contradictory. This lint should not trigger if the `assert!` is in a macro itself.
If I understand it correctly, we were first creating a type with a
`RegionKind::ReErased` region and then deleted it again in
`util::implements_trait` with:
cx.tcx.erase_regions(&ty);
causing the type query to fail.
It looks like using `ReEmpty` works around that deletion.
Fix `cast_sign_loss` false positive
This checks if the value is a non-negative constant before linting about
losing the sign.
Because the `constant` function doesn't handle const functions, we check if
the value is from a call to a `max_value` function directly. A utility method
called `get_def_path` was added to make checking for the function paths
easier.
Fixes#2728
Adding lint test for excessive LOC.
This is a WIP for #2377. Just wanted to pull in because I had a few questions:
1. Is it okay that I'm approaching this via counting by looking at each line in the snippet instead of looking at the AST tree? If there's another way to do it, I want to make sure I'm doing the correct way, but I wasn't sure since the output AST JSON doesn't seem to contain whitespace.
2. My function is definitely going to trigger the lint, so also wanted to see if there was something obvious I could do to reduce it.
3. Are the two tests fine, or is there something obvious I'm missing?
4. Obviously bigger question - am I approaching the line count correctly. Current strategy is count a line if it contains some code, so skip if it's just comments or empty.
`hir::Ty` doesn't seem to know anything about type bounds and
`cx.tcx.type_of(def_id)` caused an ICE when it was passed a generic type
with a bound:
```
src/librustc_typeck/collect.rs:1311: unexpected non-type Node::GenericParam: Type { default: None, synthetic: None }
```
Converting it to a proper `Ty` fixes the ICE and catches a few more
places where the lint applies.
This checks if the value is a non-negative constant before linting about
losing the sign.
Because the `constant` function doesn't handle const functions, we check if
the value is from a call to a `max_value` function directly. A utility method
called `get_def_path` was added to make checking for the function paths
easier.
Fixes#2728
Add initial version of const_fn lint
This adds an initial version of a lint that can tell if a function could be `const`.
TODO:
- [x] Finish up the docs
- [x] Fix the ICE
cc #2440
Prevent incorrect cast_lossless suggestion in const_fn
`::from` is not a const fn, so applying the suggestion of
`cast_lossless` would fail to compile. The fix is to skip the lint if
the cast is found inside a const fn.
Fixes#3656
Fix `expect_fun_call` lint suggestions
This commit corrects some bad suggestions produced by the
`expect_fun_call` lint and enables `rust-fix` checking on the tests.
Addresses #3630
`::from` is not a const fn, so applying the suggestion of
`cast_lossless` would fail to compile. The fix is to skip the lint if
the cast is found inside a const fn.
Fix dogfood tests on Appveyor
This introduces a work-around for a bug in rustup.rs when excuting
cargo from a custom toolchain. Instead of trusting rustup to
invoke cargo from one of the release channels we just invoke
nightly cargo directly.
This introduces a work-around for a bug in rustup.rs when excuting
cargo from a custom toolchain. Instead of trusting rustup to
invoke cargo from one of the release channels we just invoke
nightly cargo directly.
* master: (58 commits)
Rustfmt all the things
Don't make decisions on values that don't represent the decision
Improving comments.
Rustup
Added rustfix to the test.
Improve span shortening.
Added "make_return" and "blockify" convenience methods in Sugg and used them in "needless_bool".
Actually check for constants.
Fixed potential mistakes with nesting. Added tests.
formatting fix
Update clippy_lints/src/needless_bool.rs
formatting fix
Fixing typo in CONTRIBUTING.md
Fix breakage due to rust-lang/rust#57651
needless bool lint suggestion is wrapped in brackets if it is an "else" clause of an "if-else" statement
Fix automatic suggestion on `use_self`.
Remove negative integer literal checks.
Fix `implicit_return` false positives.
Run rustfmt
Fixed breakage due to rust-lang/rust#57489
...
Fix automatic suggestion on `use_self`.
In an example like this:
```rust
impl Example {
fn fun_1() { }
fn fun_2() {
Example::fun_1();
}
}
```
Clippy tries to replace `Example::fun_1` with `Self`, loosing `::fun_1` in the process, it should rather try to replace `Example` with `Self`.
**Question**
- There may be other paths that need the same treatment, but I'm not sure I understand them fully:
- e648adf086/clippy_lints/src/use_self.rs (L94-L96)
- e648adf086/clippy_lints/src/use_self.rs (L225-L229)
Fix `implicit_return` false positives.
Fixes the following false positives:
- linting on `if let` without `else` in a `loop` even with a present `return`
- linting on `unreachable!()`
Catch up with `format_args` change
Catches up with a change in rust-lang/rust#57537. (Since the optimization is optional, this clippy PR can be merged before the rustc PR.)
Happened to fix a bug in `expect_fun_call`, that is the lint ignores more than
one arguments to `format`.
```
warning: use of `expect` followed by a function call
--> src/main.rs:2:17
|
2 | Some("foo").expect(format!("{} {}", 1, 2).as_ref());
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try this: `unwrap_or_else(|| panic!("{} {}", 1))`
|
```
Catches up with a change in rust-lang/rust#57537
Happened to fix a bug in `expect_fun_call`, that is the lint ignores more than
one arguments to `format`.
`cloned` requires that the elements of the iterator must be references. This
change determines if that is the case by examining the type of the closure
argument and suggesting `.cloned` only if it is a reference. When the closure
argument is not a reference, it suggests removing the `map` call instead.
A minor problem with this change is that the new check sometimes overlaps
with the `clone_on_copy` lint.
Fixes#498
Restrict `use_self` on nested items
Fixes#3637Fixes#3463
These changes make it so that nested items aren't visited any more by the `use_self` lint.
I think visiting nested items should be possible (so that it uses a different `item_path` for the nested item), but I'm not sure whether it's viable and what the best approach would be.
- Can `item_path` be changed to a new `Self` path before visiting the item, and then changing it back afterwards?
- Alternatively, could a new visitor be created, re-using `check_trait_method_impl_decl`?
Revert the random_state lint.
Remove the random_state lint until it or rustc has been fixed to no longer crash with debug assertions (see #3628)
We can't update clippy in the rustc repo because of this which is blocking nightlies because toolstate is already broken.
fixes#3628
Add run-rustfix where it already works
This PR adds `// run-rustfix` headers to tests for `MachineApplicable` lints where
applying the suggestions works without any errors.
Trigger `use_self` lint in local macros
Closes#2098
The test currently only covers local macros. #2098 suggested this:
> You could add the macro in question into the `mini_macro` subcrate
But that doesn't work for a `macro_rules`:
```
error: cannot export macro_rules! macros from a `proc-macro` crate type currently
```
So I suggest leaving out the test for external macros, as using `in_external_macro` seems straigtforward enough. Alternatives would be to use to add an additional crate (overkill if you ask me), or test with a `proc-macro`.
UI test cleanup: Extract lint from methods.rs test
Extracts the `result_map_unwrap_or_else` lint into a separate test file.
This also extracts the `IteratorFalsePositives` struct and impl into
`auxiliary/option_helpers.rs`.
cc #2038
Integrate rustfix into Clippy test suite
Once the [PR to compiletest-rs](https://github.com/laumann/compiletest-rs/pull/151) is reviewed and merged this fixes#2376.
I will create a separate tracking issue for adding `run-rustfix` to all tests.
Only trigger `infinite_iter` lint for infinitely allocating `collect()` calls
Fixes #3538
~Oh, I guess this should actually check other methods like `count` as well, not only `collect()`.~
Never mind, `collect` is the only of these functions that allocates a data structure.
Fix if_same_then_else false positive
This fixes false positive in #3559.
The problem was that `SpanlessEq` does not check patterns in declarations. So this two blocks considered equal.
```rust
if true {
let (x, y) = foo();
} else {
let (y, x) = foo();
}
```
Not sure if the proposed change is safe as `SpanlessEq` is used extensively in other lints, but I tried hard to come up with counterexample and failed.
Merge new_without_default_derive into new_without_default
Closes#3525, deprecating new_without_default_derive and moving both lints into new_without_default.
Teach `suspicious_else_formatting` about `if .. {..} {..}`
We essentially treat bare blocks `{..}` identically to `if .. {..}`, except for different lint messages.
Fixes#3044
There is no map_unit_fn.rs whose output would be diffed with map_unit_fn.stderr
map_unit_fn.stderr was renamed 8 months ago from option_map_unit_fn.stderr
but option_map_unit_fn.{stderr,rs} both remain and are in use.
Revert "Merge pull request #3257 from o01eg/remove-sysroot"
This reverts commit 041c49c1ed, reversing
changes made to 1df5766cbb.
The PR broke running a cargo-install'd clippy.
The installed clippy would not be able to find a crate for std.
Fixes#3523Reopens#2874
Implements lint for order comparisons against bool (#3438)
As described on issue #3438, this change implements linting for `>` and `<` comparisons against both `boolean` literals and between expressions.
Adds lint for Vec<Box<T: Sized>>
This adds, and subsequently closes#3530. This is the first time I've ever worked with anything remotely close to internal Rust code, so I'm very much unsure about the if_chain! to figure this out!
I can't get rustfmt working on WSL with nightly 2018-12-07:
`error: component 'rustfmt' for target 'x86_64-unknown-linux-gnu' is unavailable for download`
Lint redundant clone of fields
Makes `redundant_clone` warn on unnecessary `foo.field.clone()` sometimes (it can detect an unnecessary clone only if the base of projection, `foo` in this case, is not used at all after that). This is enough for cases like `returns_tuple().0.clone()`.
Instead of searching for all the successive expressions after a vector
allocation, check only the first expression.
This is done to minimize the amount of false positives of the lint.
Add lint to detect slow zero-filled vector initialization. It detects
when a vector is zero-filled with extended with `repeat(0).take(len)`
or `resize(len, 0)`.
This zero-fillings are usually slower than simply using `vec![0; len]`.
3353: float support added for mistyped_literal_suffixes lint r=mikerite a=Maxgy
I implemented the mistyped_literal_suffixes lint for float literals.
```
#![allow(unused_variables)]
fn main() {
let x = 1E2_32;
let x = 75.22_64;
}
```
Given the above, the additional check suggests the variables to be written as `let x = 1E2_f32` and `let x = 75.22_f64`.
Fixes#3167
Co-authored-by: Maxwell Anderson <maxwell.brayden.anderson@gmail.com>
`possible_missing_comma` should only trigger when the binary operator has
unary equivalent. Otherwise, it's not possible to insert a comma without
breaking compilation. The operators identified were `+`, `&`, `*` and `-`.
This fixes the specific examples given in issues #3244 and #3396
but doesn't address the conflict this lint has with the style of starting
a line with a binary operator.
3397: UI test cleanup: Extract expect_fun_call tests r=matthiaskrgr a=phansch
Note that the new stderr file does not include a `shadow-unrelated`
error, because the new UI test file does not use `#![warn(clippy::all)]`
cc #2038
3398: UI test cleanup: Extract match_overlapping_arm tests r=matthiaskrgr a=phansch
cc #2038
Co-authored-by: Philipp Hansch <dev@phansch.net>
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>
