| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Previously, if you denied the old name of a renamed lint, it would warn
about using the new name, but otherwise do nothing. Now, it will behave
the same as if you'd used the new name.
|
|
|
|
Fix #82488
|
|
Changes from 81473 extended the dead code lint with an ability to detect
fields that are written to but never read from. The implementation skips
over fields on the left hand side of an assignment, without marking them
as live.
A field access might involve an automatic dereference and de-facto read
the field. Conservatively mark expressions with deref adjustments as
live to avoid generating false positive warnings.
|
|
Move some tests to more reasonable directories - 4
cc #81941
|
|
Add 'consider using' message to overflowing_literals
Fixes #79744.
Ironically, the `overflowing_literals` handler for binary or hex already
had this message! You would think it would be the other way around :)
cc ```@scottmcm```
|
|
|
|
|
|
|
|
Types with a hidden niche are not known to be non-null
Fixes #79787.
|
|
Add checking for no_mangle to unsafe_code lint
fixes #72188
r? `@estebank`
|
|
Add test for #75158
This also shifts some type-size related tests into a new directory, so that we keep the number of files at the root down.
Closes #75158
|
|
|
|
|
|
introduce future-compatibility warning for forbidden lint groups
We used to ignore `forbid(group)` scenarios completely. This changed in #78864, but that led to a number of regressions (#80988, #81218).
This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect.
r? ``@Mark-Simulacrum``
|
|
|
|
We used to ignore `forbid(group)` scenarios completely. This changed
in #78864, but that led to a number of regressions (#80988, #81218).
This PR introduces a future compatibility warning for the case where
a group is forbidden but then an individual lint within that group
is allowed. We now issue a FCW when we see the "allow", but permit
it to take effect.
|
|
Fixes #81531
When we buffer an early lint for a macro invocation,
we need to determine which NodeId to take the lint level from.
Currently, we use the `NodeId` of the closest def parent. However, if
the macro invocation is inside the desugared closure from an `async fn`
or async closure, that `NodeId` does not actually exist in the AST.
This commit explicitly calls `check_lint` for the `NodeId`s of closures
desugared from async expressions, ensuring that we do not miss any
buffered lints.
|
|
Fix invalid camel case suggestion involving unicode idents
Follow up to #77805.
|
|
|
|
Warn write-only fields
cc `@Boscop's` example in #49256.
|
|
Follow up to #77805.
|
|
|
|
cc #79813
This PR adds an allow-by-default future-compatibility lint
`SEMICOLON_IN_EXPRESSIONS_FROM_MACROS`. It fires when a trailing semicolon in a
macro body is ignored due to the macro being used in expression
position:
```rust
macro_rules! foo {
() => {
true; // WARN
}
}
fn main() {
let val = match true {
true => false,
_ => foo!()
};
}
```
The lint takes its level from the macro call site, and
can be allowed for a particular macro by adding
`#[allow(semicolon_in_expressions_from_macros)]`.
The lint is set to warn for all internal rustc crates (when being built
by a stage1 compiler). After the next beta bump, we can enable
the lint for the bootstrap compiler as well.
|
|
Do not mark unit variants as used when in path pattern
Record that we are processing a pattern so that code responsible for
handling path resolution can correctly decide whether to mark it as
used or not.
Closes #76788.
|
|
Generate metadata by iterating on DefId instead of traversing the HIR tree 1/N
Sample from #80347.
|
|
|
|
Record that we are processing a pattern so that code responsible for
handling path resolution can correctly decide whether to mark it as
used or not.
|
|
- Don't add backticks for the reason a lint was removed. This is almost
never a code block, and when it is the backticks should be in the reason
itself.
- Don't assume clippy is the only tool that needs to be checked for
backwards compatibility
|
|
Address comments
Update limits
|
|
|
|
|
|
|
|
|
|
|
|
refactor: removing library/alloc/src/vec/mod.rs ignore-tidy-filelength
This PR removes the need for ignore-tidy-filelength for library/alloc/src/vec/mod.rs which is part of the issue #60302
It is probably easiest to review this PR by looking at it commit by commit rather than looking at the overall diff.
|
|
Lint on redundant trailing semicolon after item
We now lint on code like this:
```rust
fn main() {
fn foo() {};
struct Bar {};
}
```
Previously, this caused warnings in Cargo, so it was disabled.
|
|
We now lint on code like this:
```rust
fn main() {
fn foo() {};
struct Bar {};
}
```
Previously, this caused warnings in Cargo, so it was disabled.
|
|
|
|
|
|
|
|
This reverts commit 02eae432e7476a0686633a8c2b7cb1d5aab1bd2c.
|
|
Fixes #79971
|
|
Ironically, the overflowing_literals handler for binary or hex already
had this message! You would think it would be the other way around :)
|
|
|
|
|
|
Tweak diagnostics on shadowing lifetimes/labels
Fixes #79610
Skip adding a new test assuming we have already sufficient tests.
|
|
|
|
Use true previous lint level when detecting overriden forbids
Previously, cap-lints was ignored when checking the previous forbid level, which
meant that it was a hard error to do so. This is different from the normal
behavior of lints, which are silenced by cap-lints; if the forbid would not take
effect regardless, there is not much point in complaining about the fact that we
are reducing its level.
It might be considered a bug that even `--cap-lints deny` would suffice to
silence the error on overriding forbid, depending on if one cares about failing
the build or precisely forbid being set. But setting cap-lints to deny is quite
odd and not really done in practice, so we don't try to handle it specially.
This also unifies the code paths for nested and same-level scopes. However, the
special case for CLI lint flags is left in place (introduced by #70918) to fix
the regression noted in #70819. That means that CLI flags do not lint on forbid
being overridden by a non-forbid level. It is unclear whether this is a bug or a
desirable feature, but it is certainly inconsistent. CLI flags are a
sufficiently different "type" of place though that this is deemed out of scope
for this commit.
r? `@pnkfelix` perhaps?
cc #77713 -- not marking as "Fixes" because of the lack of proper unused attribute handling in this PR
|
