| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
Fix internal `default_hash_types` lint to use resolved path
I run into false positives now and then (mostly in Clippy) when I want to name some util after HashMap.
|
|
shrinking the deprecated span
ref: https://github.com/rust-lang/rust/pull/85617#issuecomment-854947988
part of #85403
r? `@estebank`
The reason is that if we use method_span directly, it will cause the in_derive_expansion judgment to fail.
|
|
Remove `missing_docs` lint on private 2.0 macros
https://github.com/rust-lang/rust/blob/798baebde1fe77e5a660490ec64e727a5d79970d/compiler/rustc_lint/src/builtin.rs#L573-L584
This code is the source of #57569. The problem is subtle, so let me point it out. This code makes the mistake of assuming that all of the macros in `krate.exported_macros` are exported.
...Yeah. For some historical reason, all `macro` macros are marked as exported, regardless of whether they actually are, which is dreadfully confusing. It would be more accurate to say that `exported_macros` currently contains only macros that have paths.
This PR renames `exported_macros` to `importable_macros`, since these macros can be imported with `use` while others cannot. It also fixes the code above to no longer lint on private `macro` macros, since the `missing_docs` lint should only appear on exported items.
Fixes #57569.
|
|
|
|
Fix double warning about illegal floating-point literal pattern
This PR fixes #86600. The problem is that the `ConstToPat` struct contains a field `include_lint_checks`, which determines whether lints should be emitted or not, but this field is currently not obeyed at one point, leading to a warning being emitted more than once. I have fixed this behavior here.
|
|
|
|
Support lint tool names in rustc command line options
When rustc is running without a lint tool such as clippy enabled, options for lints such as `clippy::foo` are meant to be ignored. This was already working for those specified by attrs, such as `#![allow(clippy::foo)]`, but this did not work for command line arguments like `-A clippy::foo`. This PR fixes that issue.
Note that we discovered this issue while discussing https://github.com/rust-lang/cargo/issues/5034.
Fixes #86628.
|
|
This change merges `check_lint_and_tool_name` into `check_lint_name` in
order to avoid having two very similar functions.
Also adds the `.stderr` file back for the test case, since apparently
it is still needed.
|
|
Previously this was using a `.stderr` file, but that does not seem to
work for all cases. This change uses `// error-pattern:` instead.
|
|
This shares a little more code between checking command line and
attribute lint specifications.
|
|
This adds a ui test to make sure rustc accepts lint arguments such as
`-A clippy::foo` when clippy is disabled.
|
|
|
|
force_warn level
|
|
|
|
Make ForceWarn a lint level.
Follow-up to #85788
cc `@rylev`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Don't pass -Z unstable-options by default for UI tests
Unconditionally passing -Z unstable-options makes it impossible to test whether an option requires unstable-options or not.
This uncovered quite a lot of bugs, I'll open issues for each. These don't strictly need to be fixed before this is merged, it just makes the diff much larger because of the changes to diagnostics.
- https://github.com/rust-lang/rust/issues/82636
- https://github.com/rust-lang/rust/issues/82637
- https://github.com/rust-lang/rust/issues/82638
|
|
- Pass it explicitly where appropriate
- Update stderr files and warnings; it turns that unstable-options has
far-reaching effects on diagnostics.
|
|
r=Mark-Simulacrum
Revert "shrinking the deprecated method span"
Reverts rust-lang/rust#85617
Fixes: #86000
r? `@Mark-Simulacrum`
|
|
|
|
|
|
r=petrochenkov
Warn against boxed DST in `improper_ctypes_definitions` lint
Fixes #85714
|
|
|
|
Support for force-warns
Implements https://github.com/rust-lang/rust/issues/85512.
This PR adds a new command line option `force-warns` which will force the provided lints to warn even if they are allowed by some other mechanism such as `#![allow(warnings)]`.
Some remaining issues:
* https://github.com/rust-lang/rust/issues/85512 mentions that `force-warns` should also be capable of taking lint groups instead of individual lints. This is not implemented.
* If a lint has a higher warning level than `warn`, this will cause that lint to warn instead. We probably want to allow the lint to error if it is set to a higher lint and is not allowed somewhere else.
* One test is currently ignored because it's not working - when a deny-by-default lint is allowed, it does not currently warn under `force-warns`. I'm not sure why, but I wanted to get this in before the weekend.
r? `@nikomatsakis`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When there are multiple macros in use, it can be difficult to tell
which one was responsible for producing an error.
|
|
|
|
|
|
Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021
This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition.
r? `@estebank`
|
|
|