Rollup of 6 pull requests
Successful merges:
- #129542 (Add regression test for #129541)
- #129755 (test: cross-edition metavar fragment specifiers)
- #130566 (Break up compiletest `runtest.rs` into smaller helper modules)
- #130585 (Add tidy check for rustdoc templates to ensure the whitespace characters are all stripped)
- #130605 (Fix feature name in test)
- #130607 ([Clippy] Remove final std paths for diagnostic item)
r? `@ghost`
`@rustbot` modify labels: rollup
[Clippy] Remove final std paths for diagnostic item
Removes the paths to SeekFrom::Start/Current that were left in #130553.
This was split off as it involves introducing a utility to check for enum ctors, as both:
- enum variants cannot be diagnostic items
- even if they could, that wouldn't help because we need to get the enum variant ctor
While adding the `is_enum_variant_ctor`, I removed both `is_diagnostic_ctor` and `is_res_diagnostic_ctor` as they are unused and never worked due to the above bullet points.
Get rid of niche selection's dependence on fields's order
Fixes#125630.
Use the optimal niche selection decided in `univariant()` rather than picking niche field manually.
r? `@the8472`
Do not expect infer/bound/placeholder/error in v0 symbol mangling
Infer/bound/placeholder/error are not encounterable during codegen. Let's make sure v0 symbol mangling doesn't "accidentally" handle them.
As for aliases (namely: projections and uv consts) these may still be encounterable because of the way that we render the def paths of items. Specifically, when we have something like:
```
struct W<T>(T);
impl<T> W<T> {
fn x() {
fn y() {}
}
}
```
The path of `y` is rendered like `crate_name::W<T>:❌:y`. Specifically, since `y` doesn't inherit the generics of the impl, we use the *identity* substitutions for that impl. If the impl has any aliases, they will remain unnormalized if they're rigid.
r? `@BoxyUwU`
[perf] skip normalizing param env if it is already normalized
If the param env is already normalized after elaboration, then we can skip a bunch of expensive operations.
> [!note]
> This makes it so that outlives predicates are no longer sorted after non-outlives predicates. Surely this won't make a semantic difference.
r? ghost
Mark the `link_cfg` feature as internal
This PR marks the `link_cfg` feature as internal because it's a perme-unstable feature, only used by `core`/`std`and `unwind`.
[Clippy] Get rid of most `std` `match_def_path` usage, swap to diagnostic items.
Part of https://github.com/rust-lang/rust-clippy/issues/5393.
This was going to remove all `std` paths, but `SeekFrom` has issues being cleanly replaced with a diagnostic item as the paths are for variants, which currently cannot be diagnostic items.
This also, as a last step, categories the paths to help with future path removals.
It's crazy to have the integer methods in something close to random
order.
The reordering makes the gaps clear: `const_i64`, `const_i128`,
`const_isize`, and `const_u16`. I guess they just aren't needed.
In `get_fn` there is a complicated set of if/elses to determine if
`hidden` visibility should be applied. There are five calls to
`LLVMRustSetVisibility` and some repetition in the comments.
This commit streamlines it a bit:
- Computes `hidden` and then uses it to determine if a single call to
`LLVMRustSetVisibility` occurs.
- Converts some of the if/elses into boolean expressions.
- Removes the repetitive comments.
Overall this makes it quite a bit shorter, and I find it easier to read.
Never patterns constitute a read for unsafety
This code is otherwise unsound if we don't emit an unsafety error here. Noticed when fixing #130528, but it's totally unrelated.
r? `@Nadrieril`
Check params for unsafety in THIR
Self-explanatory. I'm not surprised this was overlooked, given the way that THIR visitors work. Perhaps we should provide a better entrypoint.
Fixes#130528
Further improve diagnostics for expressions in pattern position
Follow-up of #118625, see #121697.
```rs
fn main() {
match 'b' {
y.0.0.1.z().f()? as u32 => {},
}
}
```
Before:
```
error: expected one of `=>`, ``@`,` `if`, or `|`, found `.`
--> src/main.rs:3:10
|
3 | y.0.0.1.z().f()? as u32 => {},
| ^ expected one of `=>`, ``@`,` `if`, or `|`
```
After:
```
error: expected a pattern, found an expression
--> src/main.rs:3:9
|
3 | y.0.0.1.z().f()? as u32 => {},
| ^^^^^^^^^^^^^^^^^^^^^^^ arbitrary expressions are not allowed in patterns
|
help: consider moving the expression to a match arm guard
|
3 | val if val == y.0.0.1.z().f()? as u32 => {},
| ~~~ +++++++++++++++++++++++++++++++++
help: consider extracting the expression into a `const`
|
2 + const VAL: /* Type */ = y.0.0.1.z().f()? as u32;
3 ~ match 'b' {
4 ~ VAL => {},
|
help: consider wrapping the expression in an inline `const` (requires `#![feature(inline_const_pat)]`)
|
3 | const { y.0.0.1.z().f()? as u32 } => {},
| +++++++ +
```
---
r? fmease
`@rustbot` label +A-diagnostics +A-parser +A-patterns +C-enhancement
