about summary refs log tree commit diff
path: root/compiler/rustc_middle/src/lint.rs
AgeCommit message (Collapse)AuthorLines
2023-01-10create helper function for `rustc_lint_defs::Level` and remove it's ↵ozkanonur-10/+1
duplicated code r=ozkanonur Signed-off-by: ozkanonur <work@onurozkan.dev>
2023-01-04rename get_parent_node to parent_idMichael Goulet-1/+1
2022-11-06fix: typoRejyr-1/+1
2022-10-16fix typoRalf Jung-1/+1
2022-10-12Apply suggestions from code reviewWaffle Maybe-9/+4
Co-authored-by: Ralf Jung <post@ralfj.de>
2022-10-12Improve docs for `struct_lint_level` function.Maybe Waffle-0/+38
2022-10-04Rollup merge of #102568 - compiler-errors:lint-unsatisfied-opaques, r=oli-obkDylan DPC-1/+3
Lint against nested opaque types that don't satisfy associated type bounds See the test failures for examples of places where this lint would fire. r? `@oli-obk`
2022-10-04Rollup merge of #102567 - compiler-errors:issue-102561, r=davidtwcoMatthias Krüger-1/+4
Delay evaluating lint primary message until after it would be suppressed Fixes #102561 Fixes #102572
2022-10-02Lint for unsatisfied nested opaquesMichael Goulet-1/+3
2022-10-02Remove a couple lifetimes that could be inferedMaybe Waffle-7/+6
2022-10-02Delay evaluating lint primary message until after it would be suppressedMichael Goulet-1/+4
2022-10-01Use a SortedMap instead of a VecMap.Camille GILLOT-2/+2
2022-10-01Compute by owner instead of HirId.Camille GILLOT-6/+19
2022-10-01Do not fetch HIR node when iterating to find lint.Camille GILLOT-7/+3
2022-10-01Move lint level computation to rustc_middle::lint.Camille GILLOT-36/+64
2022-10-01Move code to rustc_lint.Camille GILLOT-149/+38
2022-10-01Remove unused tool_name.Camille GILLOT-2/+0
2022-10-01Compute `lint_levels` by definitionDeadbeef-19/+92
2022-10-01Move lint level source explanation to the bottomMaybe Waffle-2/+1
2022-10-01Refactor rustc lint APIMaybe Waffle-8/+24
2022-09-22Revert "Auto merge of #101620 - cjgillot:compute_lint_levels_by_def, r=oli-obk"Camille GILLOT-98/+124
This reverts commit 2cb9a65684dba47c52de8fa938febf97a73e70a9, reversing changes made to 750bd1a7ff3e010611b97ee75d30b7cbf5f3a03c.
2022-09-22Revert "Auto merge of #101862 - cjgillot:lint-regression, r=oli-obk"Camille GILLOT-1/+1
This reverts commit bc7b17cfe3bf08b618d1c7b64838053faeb1f590, reversing changes made to 5253b0a0a1f366fad0ebed57597fcf2703b9e893.
2022-09-15Do not fetch HIR node when iterating to find lint.Camille GILLOT-1/+1
2022-09-14Remove unused tool_name.Camille GILLOT-2/+0
2022-09-14Move some code and add comments.Camille GILLOT-180/+83
2022-09-14Compute `lint_levels` by definitionDeadbeef-19/+92
2022-07-13Rename `debugging_opts` to `unstable_opts`Joshua Nelson-1/+1
This is no longer used only for debugging options (e.g. `-Zoutput-width`, `-Zallow-features`). Rename it to be more clear.
2022-07-05lint: `LintDiagnosticBuilder` into `rustc_errors`David Wood-26/+1
Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-30middle: translation in `LintDiagnosticBuilder`David Wood-2/+3
Accept `DiagnosticMessage` in `LintDiagnosticBuilder::build` so that lints can be built with translatable diagnostic messages. Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-16Support lint expectations for `--force-warn` lints (RFC 2383)xFrednet-5/+11
2022-05-08Move lint expectation checking into a separate query (RFC 2383)xFrednet-1/+6
2022-04-05span: move `MultiSpan`David Wood-2/+2
`MultiSpan` contains labels, which are more complicated with the introduction of diagnostic translation and will use types from `rustc_errors` - however, `rustc_errors` depends on `rustc_span` so `rustc_span` cannot use types like `DiagnosticMessage` without dependency cycles. Introduce a new `rustc_error_messages` crate that can contain `DiagnosticMessage` and `MultiSpan`. Signed-off-by: David Wood <david.wood@huawei.com>
2022-03-30Spellchecking compiler commentsYuri Astrakhan-1/+1
This PR cleans up the rest of the spelling mistakes in the compiler comments. This PR does not change any literal or code spelling issues.
2022-03-20Filter OnceNote in diagnostic infra.Camille GILLOT-38/+16
2022-03-16rustc_error: make ErrorReported impossible to constructmark-9/+17
There are a few places were we have to construct it, though, and a few places that are more invasive to change. To do this, we create a constructor with a long obvious name.
2022-03-07Handle `#[expect(unfulfilled_lint_expectations)]` with a lint messagexFrednet-2/+10
2022-03-02Use Vec for expectations to have a constant order (RFC-2383)xFrednet-1/+1
2022-03-02Address review commentsxFrednet-1/+1
2022-03-02Emit `unfullfilled_lint_expectation` using a `HirId` for performance (RFC-2383)xFrednet-11/+2
2022-03-02Make `LintExpectationId` stable between compilation sessions (RFC-2383)xFrednet-2/+1
2022-03-02Set `LintExpectationId` in level and collect fulfilled ones (RFC-2383)xFrednet-2/+40
* Collect lint expectations and set expectation ID in level (RFC-2383) * Collect IDs of fulfilled lint expectations from diagnostics (RFC 2383)
2022-03-02Added `Expect` lint level and attribute (RFC-2383)xFrednet-0/+22
* Also added the `LintExpectationId` which will be used in future commits
2022-02-23rustc_errors: let `DiagnosticBuilder::emit` return a "guarantee of emission".Eduard-Mihai Burtescu-3/+3
2022-02-23rustc_errors: handle `force_warn` only through `DiagnosticId::Lint`.Eduard-Mihai Burtescu-4/+2
2022-02-23Replace `&mut DiagnosticBuilder`, in signatures, with `&mut Diagnostic`.Eduard-Mihai Burtescu-4/+4
2022-02-20Improve `unused_unsafe` lintFrank Steffahn-62/+73
Main motivation: Fixes some issues with the current behavior. This PR is more-or-less completely re-implementing the unused_unsafe lint; it’s also only done in the MIR-version of the lint, the set of tests for the `-Zthir-unsafeck` version no longer succeeds (and is thus disabled, see `lint-unused-unsafe.rs`). On current nightly, ```rs unsafe fn unsf() {} fn inner_ignored() { unsafe { #[allow(unused_unsafe)] unsafe { unsf() } } } ``` doesn’t create any warnings. This situation is not unrealistic to come by, the inner `unsafe` block could e.g. come from a macro. Actually, this PR even includes removal of one unused `unsafe` in the standard library that was missed in a similar situation. (The inner `unsafe` coming from an external macro hides the warning, too.) The reason behind this problem is how the check currently works: * While generating MIR, it already skips nested unsafe blocks (i.e. unsafe nested in other unsafe) so that the inner one is always the one considered unused * To differentiate the cases of no unsafe operations inside the `unsafe` vs. a surrounding `unsafe` block, there’s some ad-hoc magic walking up the HIR to look for surrounding used `unsafe` blocks. There’s a lot of problems with this approach besides the one presented above. E.g. the MIR-building uses checks for `unsafe_op_in_unsafe_fn` lint to decide early whether or not `unsafe` blocks in an `unsafe fn` are redundant and ought to be removed. ```rs unsafe fn granular_disallow_op_in_unsafe_fn() { unsafe { #[deny(unsafe_op_in_unsafe_fn)] { unsf(); } } } ``` ``` error: call to unsafe function is unsafe and requires unsafe block (error E0133) --> src/main.rs:13:13 | 13 | unsf(); | ^^^^^^ call to unsafe function | note: the lint level is defined here --> src/main.rs:11:16 | 11 | #[deny(unsafe_op_in_unsafe_fn)] | ^^^^^^^^^^^^^^^^^^^^^^ = note: consult the function's documentation for information on how to avoid undefined behavior warning: unnecessary `unsafe` block --> src/main.rs:10:5 | 9 | unsafe fn granular_disallow_op_in_unsafe_fn() { | --------------------------------------------- because it's nested under this `unsafe` fn 10 | unsafe { | ^^^^^^ unnecessary `unsafe` block | = note: `#[warn(unused_unsafe)]` on by default ``` Here, the intermediate `unsafe` was ignored, even though it contains a unsafe operation that is not allowed to happen in an `unsafe fn` without an additional `unsafe` block. Also closures were problematic and the workaround/algorithms used on current nightly didn’t work properly. (I skipped trying to fully understand what it was supposed to do, because this PR uses a completely different approach.) ```rs fn nested() { unsafe { unsafe { unsf() } } } ``` ``` warning: unnecessary `unsafe` block --> src/main.rs:10:9 | 9 | unsafe { | ------ because it's nested under this `unsafe` block 10 | unsafe { unsf() } | ^^^^^^ unnecessary `unsafe` block | = note: `#[warn(unused_unsafe)]` on by default ``` vs ```rs fn nested() { let _ = || unsafe { let _ = || unsafe { unsf() }; }; } ``` ``` warning: unnecessary `unsafe` block --> src/main.rs:9:16 | 9 | let _ = || unsafe { | ^^^^^^ unnecessary `unsafe` block | = note: `#[warn(unused_unsafe)]` on by default warning: unnecessary `unsafe` block --> src/main.rs:10:20 | 10 | let _ = || unsafe { unsf() }; | ^^^^^^ unnecessary `unsafe` block ``` *note that this warning kind-of suggests that **both** unsafe blocks are redundant* -------------------------------------------------------------------------------- I also dislike the fact that it always suggests keeping the outermost `unsafe`. E.g. for ```rs fn granularity() { unsafe { unsafe { unsf() } unsafe { unsf() } unsafe { unsf() } } } ``` I prefer if `rustc` suggests removing the more-course outer-level `unsafe` instead of the fine-grained inner `unsafe` blocks, which it currently does on nightly: ``` warning: unnecessary `unsafe` block --> src/main.rs:10:9 | 9 | unsafe { | ------ because it's nested under this `unsafe` block 10 | unsafe { unsf() } | ^^^^^^ unnecessary `unsafe` block | = note: `#[warn(unused_unsafe)]` on by default warning: unnecessary `unsafe` block --> src/main.rs:11:9 | 9 | unsafe { | ------ because it's nested under this `unsafe` block 10 | unsafe { unsf() } 11 | unsafe { unsf() } | ^^^^^^ unnecessary `unsafe` block warning: unnecessary `unsafe` block --> src/main.rs:12:9 | 9 | unsafe { | ------ because it's nested under this `unsafe` block ... 12 | unsafe { unsf() } | ^^^^^^ unnecessary `unsafe` block ``` -------------------------------------------------------------------------------- Needless to say, this PR addresses all these points. For context, as far as my understanding goes, the main advantage of skipping inner unsafe blocks was that a test case like ```rs fn top_level_used() { unsafe { unsf(); unsafe { unsf() } unsafe { unsf() } unsafe { unsf() } } } ``` should generate some warning because there’s redundant nested `unsafe`, however every single `unsafe` block _does_ contain some statement that uses it. Of course this PR doesn’t aim change the warnings on this kind of code example, because the current behavior, warning on all the inner `unsafe` blocks, makes sense in this case. As mentioned, during MIR building all the unsafe blocks *are* kept now, and usage is attributed to them. The way to still generate a warning like ``` warning: unnecessary `unsafe` block --> src/main.rs:11:9 | 9 | unsafe { | ------ because it's nested under this `unsafe` block 10 | unsf(); 11 | unsafe { unsf() } | ^^^^^^ unnecessary `unsafe` block | = note: `#[warn(unused_unsafe)]` on by default warning: unnecessary `unsafe` block --> src/main.rs:12:9 | 9 | unsafe { | ------ because it's nested under this `unsafe` block ... 12 | unsafe { unsf() } | ^^^^^^ unnecessary `unsafe` block warning: unnecessary `unsafe` block --> src/main.rs:13:9 | 9 | unsafe { | ------ because it's nested under this `unsafe` block ... 13 | unsafe { unsf() } | ^^^^^^ unnecessary `unsafe` block ``` in this case is by emitting a `unused_unsafe` warning for all of the `unsafe` blocks that are _within a **used** unsafe block_. The previous code had a little HIR traversal already anyways to collect a set of all the unsafe blocks (in order to afterwards determine which ones are unused afterwards). This PR uses such a traversal to do additional things including logic like _always_ warn for an `unsafe` block that’s inside of another **used** unsafe block. The traversal is expanded to include nested closures in the same go, this simplifies a lot of things. The whole logic around `unsafe_op_in_unsafe_fn` is a little complicated, there’s some test cases of corner-cases in this PR. (The implementation involves differentiating between whether a used unsafe block was used exclusively by operations where `allow(unsafe_op_in_unsafe_fn)` was active.) The main goal was to make sure that code should compile successfully if all the `unused_unsafe`-warnings are addressed _simultaneously_ (by removing the respective `unsafe` blocks) no matter how complicated the patterns of `unsafe_op_in_unsafe_fn` being disallowed and allowed throughout the function are. -------------------------------------------------------------------------------- One noteworthy design decision I took here: An `unsafe` block with `allow(unused_unsafe)` **is considered used** for the purposes of linting about redundant contained unsafe blocks. So while ```rs fn granularity() { unsafe { //~ ERROR: unnecessary `unsafe` block unsafe { unsf() } unsafe { unsf() } unsafe { unsf() } } } ``` warns for the outer `unsafe` block, ```rs fn top_level_ignored() { #[allow(unused_unsafe)] unsafe { #[deny(unused_unsafe)] { unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block } } } ``` warns on the inner ones.
2022-02-01update `FutureIncompatibilityReason`lcnr-25/+22
2022-01-24rustc_errors: remove `allow_suggestions` from `DiagnosticBuilder`.Eduard-Mihai Burtescu-1/+1
2021-12-19Auto merge of #92099 - matthiaskrgr:rollup-4gwv67m, r=matthiaskrgrbors-1/+1
Rollup of 7 pull requests Successful merges: - #91141 (Revert "Temporarily rename int_roundings functions to avoid conflicts") - #91984 (Remove `in_band_lifetimes` from `rustc_middle`) - #92028 (Sync portable-simd to fix libcore build for AVX-512 enabled targets) - #92042 (Enable `#[thread_local]` for all windows-msvc targets) - #92071 (Update example code for Vec::splice to change the length) - #92077 (rustdoc: Remove unused `collapsed` field) - #92081 (rustdoc: Remove unnecessary `need_backline` function) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-12-19Auto merge of #91957 - nnethercote:rm-SymbolStr, r=oli-obkbors-1/+1
Remove `SymbolStr` This was originally proposed in https://github.com/rust-lang/rust/pull/74554#discussion_r466203544. As well as removing the icky `SymbolStr` type, it allows the removal of a lot of `&` and `*` occurrences. Best reviewed one commit at a time. r? `@oli-obk`