Actually fix ICE from #96583
PR #96746 fixed a very similar bug, so the same logic is used in a different place.
I originally concluded that the two issues (#96583 and #96738) were identical by comparing the backtrace, but I didn't look close enough.
Warn on unused `#[doc(hidden)]` attributes on trait impl items
[Zulip conversation](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/.E2.9C.94.20Validy.20checks.20for.20.60.23.5Bdoc.28hidden.29.5D.60).
Whether an associated item in a trait impl is shown or hidden in the documentation entirely depends on the corresponding item in the trait declaration. Rustdoc completely ignores `#[doc(hidden)]` attributes on impl items. No error or warning is emitted:
```rust
pub trait Tr { fn f(); }
pub struct Ty;
impl Tr for Ty { #[doc(hidden)] fn f() {} }
// ^^^^^^^^^^^^^^ ignored by rustdoc and currently
// no error or warning issued
```
This may lead users to the wrong belief that the attribute has an effect. In fact, several such cases are found in the standard library (I've removed all of them in this PR).
There does not seem to exist any incentive to allow this in the future either: Impl'ing a trait for a type means the type *fully* conforms to its API. Users can add `#[doc(hidden)]` to the whole impl if they want to hide the implementation or add the attribute to the corresponding associated item in the trait declaration to hide the specific item. Hiding an implementation of an associated item does not make much sense: The associated item can still be found on the trait page.
This PR emits the warn-by-default lint `unused_attribute` for this case with a future-incompat warning.
`@rustbot` label T-compiler T-rustdoc A-lint
Remove `#[rustc_deprecated]`
This removes `#[rustc_deprecated]` and introduces diagnostics to help users to the right direction (that being `#[deprecated]`). All uses of `#[rustc_deprecated]` have been converted. CI is expected to fail initially; this requires #95958, which includes converting `stdarch`.
I plan on following up in a short while (maybe a bootstrap cycle?) removing the diagnostics, as they're only intended to be short-term.
Support tool lints with the `#[expect]` attribute (RFC 2383)
This PR fixes the ICE https://github.com/rust-lang/rust/issues/94953 by making the assert for converted expectation IDs conditional.
Additionally, it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way, I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints.
The number of changes comes from the long test file. This may look like a monster PR, this may smell like a monster PR and this may be a monster PR, but it's a harmless monster. 🦕
---
Closes: https://github.com/rust-lang/rust/issues/94953
cc: https://github.com/rust-lang/rust/issues/85549
r? `@wesleywiser`
cc: `@rust-lang/rustdoc`
Add more diagnostic items
This just adds a handful diagnostic items I noticed were missing.
Would it be worth doing this for all of the remaining types? I'm willing to do it if it'd be helpful.
Track if a where bound comes from a impl Trait desugar
With https://github.com/rust-lang/rust/pull/93803 `impl Trait` function arguments get desugared to hidden where bounds. However, Clippy needs to know if a bound was originally a `impl Trait` or an actual bound. This adds a field to the `WhereBoundPredicate` struct to keep track of this information during AST->HIR lowering.
r? `@cjgillot`
cc `@estebank` (as the reviewer of #93803)
Improve error for missing cmake
This PR updates the error message for a missing `cmake` to be more in line with the error message for a missing installation of `ninja`.
The original issue, (#90679), suggests that both `ninja` and `cmake` are only needed for building LLVM, so I have included the suggestion from `ninja` to set `download-ci-llvm = true` if the user would rather download LLVM. If `cmake` actually is used in other areas, I can remove that part of the message.
Fixes: #90679
Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions
A new clippy lint for issue 93883 (https://github.com/rust-lang/rust/issues/93883). Relies on a new trait in `marker` (called `SignificantDrop` to enable linting), which is why this PR is for the rust-lang repo and not the clippy repo.
changelog: new lint [`significant_drop_in_scrutinee`]
Rollup of 10 pull requests
Successful merges:
- #96336 (Link to correct `as_mut` in docs for `pointer::as_ref`)
- #96586 (Add aliases for std::fs::canonicalize)
- #96667 (Add regression test)
- #96671 (Remove hard links from `env::current_exe` security example)
- #96726 (Add regression and bug tests)
- #96756 (Enable compiler-docs by default for `compiler`, `codegen`, and `tools` profiles)
- #96757 (Don't constantly rebuild clippy on `x test src/tools/clippy`.)
- #96769 (Remove `adx_target_feature` feature from active features list)
- #96777 (Make the test `check-pass` not to produce a JSON file)
- #96822 (Enforce quote rule for JS source code)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Make the test `check-pass` not to produce a JSON file
`run-pass` produces a JSON file when enabling save analysis.
The original ICE happened on `cargo check`, moreover **without** the `generic_const_exprs` feature, so `check-pass` should be enough.
Don't constantly rebuild clippy on `x test src/tools/clippy`.
This happened because the `SYSROOT` variable was set for `x test`, but not `x build`.
Set it consistently for both to avoid unnecessary rebuilds.
This is a very small step towards https://github.com/rust-lang/rust/issues/76495.
Enable compiler-docs by default for `compiler`, `codegen`, and `tools` profiles
I had this overridden locally for a while and realized just now it should probably just be a default.
Enable cfg checking of cargo features for everything but std
This PR enable `cfg` checking of cargo features for everything but std, it also adds a `FIXME` to myself.
> Note: `std`, `alloc` and `core` imports some dependencies by #[path] (like
> backtrace, core_simd, std_float, ...), those dependencies have their own features
> but cargo isn't involved in the #[path] and so cannot pass the complete list of
> features, so for that reason we don't enable checking of features for std.
r? `@Mark-Simulacrum`
With #93803 `impl Trait` function arguments get desugared to hidden
where bounds. However, Clippy needs to know if a bound was originally a
impl Trait or an actual bound. This adds a field to the
`WhereBoundPredicate` struct to keep track of this information during
HIR lowering.
Change eslint rules from configuration comments to configuration file
Repeatedly declaring eslint rules in source files is an annoying thing, we should move those rules into the eslint configuration file.
r? ``@GuillaumeGomez``
diagnostics: port more diagnostics to derive + add support for `Vec` fields
- Port "unconstrained opaque type" diagnostic to using the derive.
- Allow `Vec` fields in diagnostic derive - enables support for diagnostics that have multiple primary spans, or have subdiagnostics repeated at multiple locations. `Vec<..>` fields in the diagnostic derive become loops in the generated code.
- Add `create_{err,warning}` - there wasn't a way to create a diagnostic from a struct and not emit it straight away.
- Port "explicit generic args w/ impl trait" diagnostic to using the derive.
r? `````@oli-obk`````
cc `````@pvdrz`````
Fix jump to def regression
https://github.com/rust-lang/rust/pull/93803 introduced a regression in the "jump to def" feature. This fixes it.
Nice side-effect: it adds a new regression test. :)
I also used this opportunity to add documentation about this unstable feature in the rustdoc book.
cc ``@cjgillot``
r? ``@notriddle``
make Size and Align debug-printing a bit more compact
In particular in `{:#?}`-mode, these take up a lot of space, so I think this is the better alternative (even though it is a bit longer in `{:?}` mode, I think it is still more readable).
We could make it even smaller by deviating further from what the actual code looks like, e.g. via something like `Size(4 bytes)`. Not sure what people would think about that?
Cc `````@oli-obk`````
