-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
False positive unfulfilled_lint_expectations
with either of --tests
or --all-targets
#130021
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
F-lint_reasons
`#![feature(lint_reasons)]`
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
Minimized: // flags: rustc --test a.rs
#![warn(missing_docs)]
#[expect(missing_docs)]
pub fn foo() {} cc @xFrednet |
This seems very relevant. rust/compiler/rustc_lint/src/builtin.rs Lines 429 to 433 in d678b81
|
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Sep 8, 2024
…chenkov Also emit `missing_docs` lint with `--test` to fulfil expectations This PR removes the "test harness" suppression of the `missing_docs` lint to be able to fulfil `#[expect]` (expectations) as it is now "relevant". I think the goal was to maybe avoid false-positive while linting on public items under `#[cfg(test)]` but with effective visibility we should no longer have any false-positive. Another possibility would be to query the lint level and only emit the lint if it's of expect level, but that is even more hacky. Fixes rust-lang#130021
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Sep 8, 2024
…chenkov Also emit `missing_docs` lint with `--test` to fulfil expectations This PR removes the "test harness" suppression of the `missing_docs` lint to be able to fulfil `#[expect]` (expectations) as it is now "relevant". I think the goal was to maybe avoid false-positive while linting on public items under `#[cfg(test)]` but with effective visibility we should no longer have any false-positive. Another possibility would be to query the lint level and only emit the lint if it's of expect level, but that is even more hacky. Fixes rust-lang#130021
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this issue
Sep 9, 2024
…chenkov Also emit `missing_docs` lint with `--test` to fulfil expectations This PR removes the "test harness" suppression of the `missing_docs` lint to be able to fulfil `#[expect]` (expectations) as it is now "relevant". I think the goal was to maybe avoid false-positive while linting on public items under `#[cfg(test)]` but with effective visibility we should no longer have any false-positive. Another possibility would be to query the lint level and only emit the lint if it's of expect level, but that is even more hacky. Fixes rust-lang#130021
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 9, 2024
Also emit `missing_docs` lint with `--test` to fulfil expectations This PR removes the "test harness" suppression of the `missing_docs` lint to be able to fulfil `#[expect]` (expectations) as it is now "relevant". I think the goal was to maybe avoid false-positive while linting on public items under `#[cfg(test)]` but with effective visibility we should no longer have any false-positive. Another possibility would be to query the lint level and only emit the lint if it's of expect level, but that is even more hacky. Fixes rust-lang#130021 try-job: x86_64-gnu-aux
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this issue
Sep 10, 2024
…chenkov Also emit `missing_docs` lint with `--test` to fulfil expectations This PR removes the "test harness" suppression of the `missing_docs` lint to be able to fulfil `#[expect]` (expectations) as it is now "relevant". I think the goal was to maybe avoid false-positive while linting on public items under `#[cfg(test)]` but with effective visibility we should no longer have any false-positive. Another possibility would be to query the lint level and only emit the lint if it's of expect level, but that is even more hacky. Fixes rust-lang#130021 try-job: x86_64-gnu-aux
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Sep 11, 2024
Also emit `missing_docs` lint with `--test` to fulfil expectations This PR removes the "test harness" suppression of the `missing_docs` lint to be able to fulfil `#[expect]` (expectations) as it is now "relevant". I think the goal was to maybe avoid false-positive while linting on public items under `#[cfg(test)]` but with effective visibility we should no longer have any false-positive. Another possibility would be to query the lint level and only emit the lint if it's of expect level, but that is even more hacky. Fixes rust-lang/rust#130021 try-job: x86_64-gnu-aux
lnicola
pushed a commit
to lnicola/rust-analyzer
that referenced
this issue
Sep 25, 2024
Also emit `missing_docs` lint with `--test` to fulfil expectations This PR removes the "test harness" suppression of the `missing_docs` lint to be able to fulfil `#[expect]` (expectations) as it is now "relevant". I think the goal was to maybe avoid false-positive while linting on public items under `#[cfg(test)]` but with effective visibility we should no longer have any false-positive. Another possibility would be to query the lint level and only emit the lint if it's of expect level, but that is even more hacky. Fixes rust-lang/rust#130021 try-job: x86_64-gnu-aux
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Nov 30, 2024
Work around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn't fixed for our MSRV at this time.
github-merge-queue bot
pushed a commit
to bytecodealliance/wasmtime
that referenced
this issue
Dec 2, 2024
* Start using `#[expect]` instead of `#[allow]` In Rust 1.81, our new MSRV, a new feature was added to Rust to use `#[expect]` to control lint levels. This new lint annotation will silence a lint but will itself cause a lint if it doesn't actually silence anything. This is quite useful to ensure that annotations don't get stale over time. Another feature is the ability to use a `reason` directive on the attribute with a string explaining why the attribute is there. This string is then rendered in compiler messages if a warning or error happens. This commit migrates applies a few changes across the workspace: * Some `#[allow]` are changed to `#[expect]` with a `reason`. * Some `#[allow]` have a `reason` added if the lint conditionally fires (mostly related to macros). * Some `#[allow]` are removed since the lint doesn't actually fire. * The workspace configures `clippy::allow_attributes_without_reason = 'warn'` as a "ratchet" to prevent future regressions. * Many crates are annotated to allow `allow_attributes_without_reason` during this transitionary period. The end-state is that all crates should use `#[expect(..., reason = "...")]` for any lint that unconditionally fires but is expected. The `#[allow(..., reason = "...")]` lint should be used for conditionally firing lints, primarily in macro-related code. The `allow_attributes_without_reason = 'warn'` level is intended to be permanent but the transitionary `#[expect(clippy::allow_attributes_without_reason)]` crate annotations to go away over time. * Fix adapter build prtest:full * Fix one-core build of icache coherence * Use `allow` for missing_docs Work around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn't fixed for our MSRV at this time. * More MSRV compat
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
F-lint_reasons
`#![feature(lint_reasons)]`
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Code
Current output
Desired output
Rationale and extra context
No response
Other cases
cargo clippy --all-targets
has the same issue withclippy::enum_glob_use
, however, there's no false positive onclippy::unreadable_literal
.Rust Version
Anything else?
Reported in rust-lang/rust-analyzer#17685.
The text was updated successfully, but these errors were encountered: