Change `unknown_lint` applicability to `MaybeIncorrect`
This small PR changes the applicability of `unknown_lint` to `MaybeIncorrect`, because the suggested lint might not be the correct one.
Here is one example where the current applicability causes a problem. Clippy has a set of internal lints guarded by a feature called `internal`. If the feature is not enabled, then the internal lints are "unknown." In that case, running `cargo clippy --fix ...` on `clippy_utils` causes lines such as the followig
26c96e3416/src/tools/clippy/clippy_utils/src/paths.rs (L51-L52)
to be changed to
```rust
#[expect(clippy::invalid_regex)] // internal lints do not know about all external crates
pub const FUTURES_IO_ASYNCREADEXT: [&str; 3] = ["futures_util", "io", "AsyncReadExt"];
```
which is not correct.
Delay ambiguity span bug in normalize query iff not rustdoc
Oli and I decided that the compiler debt of adding another usage of `tcx.sess.opts.actually_rustdoc` is fine, because we don't really want to add more complexity to the normalize query, and moving rustdoc to use fulfill normalization (`fully_normalize`, i.e. not use the normalize query) is unnecessary overhead given that it's skipping binders and stuff.
r? oli-obk
Fixes#102827Fixes#103181
Handle return-position `impl Trait` in traits properly in `register_hidden_type`
The bounds that we get by calling `bound_explicit_item_bounds` from an RPITIT have projections, not opaques, but when we're *registering* an opaque, we want to treat it like an opaque.
Coincidentally fixes#102688 as well, which makes sense, since that was failing because we were inferring an opaque type to be equal to itself (opaque cycle error => "cannot resolve opaque type").
Fixes#103352
r? ```@oli-obk```
Do not suggest trivially false const predicates
Pass through constness to `predicate_can_apply` and don't suggest other impls if it's satisfied but not const.
Fixes#103267
Introduce `subst_iter` and `subst_iter_copied` on `EarlyBinder`
Makes working with bounds lists a bit easier, which I seem to do a lot.
Specifically, means that we don't need to do `.transpose_iter().map(|(pred, _)| *pred)` every time we want to iterate through an `EarlyBinder<&'tcx [(Predicate, Span)]>` (and even then, still have to call `subst` later), which was a very awkward idiom imo.
Move MSRV tests into the lint specific test files
There are currently two ways MSRV tests are done in the ui test suite, adding a case to the `#![clippy::msrv = "1.0"]` `tests/ui/min_rust_version_attr.rs` or adding the two `msrv_1_xx` functions to the test file of the lint in question
This updates the clippy book to suggest the `msrv_1_xx` style, and replaces the tests in `tests/ui/min_rust_version_attr.rs` with ones of that style
Almost the entire diff is just moving stuff around as a result, I made sure to check the line numbers the lints are emitted at correspond with the right `msrv` case, so feel free to only skim that part
changelog: none
Rust's niche handling allows for wrapping valid ranges with end < start;
for instance, a valid range with start=43 and end=41 means a niche of
42. Most places in the compiler handle this correctly, but
ty_find_init_error assumed that `lo > 0` means the type cannot contain a
zero.
Fix it to handle wrapping ranges.
Add a test to cover this case.
Add `lintcheck` to packages linted by `dogfood` test
Currently, `lintcheck` is not checked by the `dogfood` test. I assume that is not intentional. If it is intentional, then this PR can be ignored.
changelog: Add `lintcheck` to packages linted by `dogfood` test
Update cargo
5 commits in 3ff044334f0567ce1481c78603aeee7211b91623..071eeaf210708219a5a1b2c4728ca2f97df7f2ae 2022-10-17 20:25:00 +0000 to 2022-10-22 01:17:55 +0000
- fix: Remove leading newline in vendor output (rust-lang/cargo#11273)
- Fix publishing with a dependency on a sparse registry (rust-lang/cargo#11268)
- Add missing edition (rust-lang/cargo#11265)
- fix(publish): Check remote git registry more than once post-publish (rust-lang/cargo#11255)
- Fix typo (rust-lang/cargo#11258)
r? `@ghost`
5 commits in 3ff044334f0567ce1481c78603aeee7211b91623..071eeaf210708219a5a1b2c4728ca2f97df7f2ae
2022-10-17 20:25:00 +0000 to 2022-10-22 01:17:55 +0000
- fix: Remove leading newline in vendor output (rust-lang/cargo#11273)
- Fix publishing with a dependency on a sparse registry (rust-lang/cargo#11268)
- Add missing edition (rust-lang/cargo#11265)
- fix(publish): Check remote git registry more than once post-publish (rust-lang/cargo#11255)
- Fix typo (rust-lang/cargo#11258)
Reduce false positives in msys2 detection
Currently msys2 will be detected by getting the file path and looking to see if it contains the substrings "msys-" and "-ptr" (or "cygwin-" and "-pty"). This risks false positives, especially with filesystem files and if `GetFileInformationByHandleEx` returns a [full path](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntqueryinformationfile#remarks).
This PR adds a check to see if the handle is a pipe before doing the substring search. Additionally, for "msys2-" or "cygwin-" it only checks if the file name starts with the substring rather than looking at the whole path.
Adjust argument type for mutable with_metadata_of (#75091)
The method takes two pointer arguments: one `self` supplying the pointer value, and a second pointer supplying the metadata.
The new parameter type more clearly reflects the actual requirements. The provenance of the metadata parameter is disregarded completely. Using a mutable pointer in the call site can be coerced to a const pointer while the reverse is not true.
In some cases, the current parameter type can thus lead to a very slightly confusing additional cast. [Example](cad93775eb).
```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;
let ptr = val as *const _ as *mut T;
let ptr = uninit.as_ptr().with_metadata_of(ptr);
```
This could then instead be simplified to:
```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;
let ptr = uninit.as_ptr().with_metadata_of(&**val);
```
Tracking issue: https://github.com/rust-lang/rust/issues/75091
``@dtolnay`` you're reviewed #95249, would you mind chiming in?
Allow semicolon after closure within parentheses in macros
#88546 added some parsing logic that if we're parsing a closure, and we're within parentheses, and a semicolon follows, then we must be parsing something erroneous like: `f(|| a; b)`, so it replaces the closure body with an error expression. However, it's valid to parse those tokens if we're within a macro, as in #103222.
This is a bit unsatisfying fix. Is there a more robust way of checking that we're within a macro?
I would also be open to removing this "_It is likely that the closure body is a block but where the braces have been removed_" check altogether at the expense of more verbose errors, since it seems very suspicious in the first place...
Fixes#103222.
rustdoc: render bounds of cross-crate GAT params
Follow-up to #102439.
Render the trait bounds of type parameters of cross-crate (generic) associated types.
`````@rustbot````` label T-rustdoc A-cross-crate-reexports
r? `````@GuillaumeGomez`````
Slightly tweak comments wrt `lint_overflowing_range_endpoint`
From the review: https://github.com/rust-lang/rust/pull/101986#discussion_r975610611
It _seemed_ that the lint was not emitted when the `if` check failed, but _actually_ this happens already in a special case and the lint is emitted outside of this function, if this function doesn't. I've cleared up the code/comments a bit, so it's more obvious :)
r? ```@estebank```
Remove byte swap of valtree hash on big endian
This addresses problem reported in #103183. The code was originally introduced in e14b34c386. (see https://github.com/rust-lang/rust/pull/96591)
On big-endian environment, this operation sequence actually put the other half from 128-bit result, thus we got different hash result on LE and BE.
stop using `ty::UnevaluatedConst` directly
best reviewed commit by commit.
simplifies #99798 because we now don't have to expand `ty::UnevaluatedConst` to `ty::Const`.
I also remember some other places where using `ty::UnevaluatedConst` directly was annoying and caused issues, though I don't quite remember what they were rn '^^
r? `@oli-obk` cc `@JulianKnodt`
Get rid of native_library projection queries
They don't seem particularly useful as I don't expect native libraries to change frequently.
Maybe they do provide significant value of keeping incremental compilation green though, I'm not sure.
The latest version of `rental` (v0.5.6) contains a fix that allows it to
compile without relying on the pretty-print back-compat hack.
Hopefully, there are no longer any crates relying on the affected
versions of the (much less popular) `procedural-masquerade` crate. This
should allow us to target the pretty-print back-compat hack specifically
to older versions of `rental`, and specifically mention upgrading to
`rental` v0.5.6 in the lint message.
