-
Notifications
You must be signed in to change notification settings - Fork 13.3k
False positive unfulfilled_lint_expectations
with either of --tests
or --all-targets
#130021
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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
github-merge-queue bot
pushed a commit
to linebender/xilem
that referenced
this issue
Mar 19, 2025
Any new widget code needs to have full docs. Not having `missing_docs` trigger by default for new widgets is quite bad. See #875 and #882 for cases where this over-broad allow has bitten us. The comment about not using `expect(missing_docs)` because of rust-analyzer is confusing to me; I don't run into an issue. It might have been rust-lang/rust#130021, which is now fixed. That comment should have had a link to an upstream issue for more context.
# for free
to join this conversation on GitHub.
Already have an account?
# 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: