Fix legacy numeric constant diag items
- missed syms for usize/isize
- missed diag items on unsigned integers
For rust-lang/rust-clippy#12312
r? ```@Nilstrieb```
Follow-up to #121272, #121361, #121667
This should be the last one 🤞 Sorry!
match lowering: define a convenient struct
Small refactor PR: `bindings` and `ascriptions` always come together so I made a struct for them. I'll have one or two fields to add to it in a later PR as well.
Add a tidy check that checks whether the fluent slugs only appear once
As ``````@Nilstrieb`````` said in https://github.com/rust-lang/rust/pull/121828#issuecomment-1972622855:
> Might make sense to have a tidy check that checks whether the fluent slugs only appear once in the source code and lint for that
there's a tidy check already for sorting
We can get the tidy check error:
```
tidy check
tidy error: /path/to/rust/compiler/rustc_const_eval/messages.ftl: message `const_eval_invalid_align` is not used
tidy error: /path/to/rust/compiler/rustc_lint/messages.ftl: message `lint_trivial_untranslatable_diag` is not used
tidy error: /path/to/rust/compiler/rustc_parse/messages.ftl: message `parse_invalid_literal_suffix` is not used
tidy error: /path/to/rust/compiler/rustc_infer/messages.ftl: message `infer_need_type_info_in_coroutine` is not used
tidy error: /path/to/rust/compiler/rustc_passes/messages.ftl: message `passes_expr_not_allowed_in_context` is not used
tidy error: /path/to/rust/compiler/rustc_passes/messages.ftl: message `passes_layout` is not used
tidy error: /path/to/rust/compiler/rustc_parse/messages.ftl: message `parse_not_supported` is not used
```
r? ``````@Nilstrieb``````
Distinguish between library and lang UB in assert_unsafe_precondition
As described in https://github.com/rust-lang/rust/pull/121583#issuecomment-1963168186, `assert_unsafe_precondition` now explicitly distinguishes between language UB (conditions we explicitly optimize on) and library UB (things we document you shouldn't do, and maybe some library internals assume you don't do).
`debug_assert_nounwind` was originally added to avoid the "only at runtime" aspect of `assert_unsafe_precondition`. Since then the difference between the macros has gotten muddied. This totally revamps the situation.
Now _all_ preconditions shall be checked with `assert_unsafe_precondition`. If you have a precondition that's only checkable at runtime, do a `const_eval_select` hack, as done in this PR.
r? RalfJung
Remove `Ord` from `ClosureKind`
Using `Ord` to accomplish a meaning of subset relationship can be hard to read. The existing uses for that are easily replaced with a `match`, and in my opinion, more readable without needing to resorting to comments to explain the intention.
cc `@compiler-errors`
Some tweaks to the parallel query cycle handler
This renames `deadlock` to `break_query_cycles`. The abort logic is moved next to the thread spawning and gives the thread a name.
Fixes https://github.com/rust-lang/rust/issues/122035.
r? ```@oli-obk```
Move metadata header and version checks together
This will make it easier to report rustc versions for older metadata formats.
Split out of https://github.com/rust-lang/rust/pull/120855
Eagerly translate `HelpUseLatestEdition` in parser diagnostics
Fixes#122130.
This makes me suspicious of these other two usage of `add_to_diagnostic()`. Would they *also* crash? I haven't attempted to construct test cases for them.
```
compiler/rustc_parse/src/parser/expr.rs
3453: errors::HelpUseLatestEdition::new().add_to_diagnostic(e);
compiler/rustc_hir_typeck/src/expr.rs
2603: HelpUseLatestEdition::new().add_to_diagnostic(&mut err);
```
This also seems like a footgun?
Misc improvements to non local defs lint implementation
This PR is a collection of small improvements I found when I [needlessly tried](https://www.github.com/rust-lang/rust/pull/120393#issuecomment-1971787475) to fix a "perf-regression" in the lint implementation.
I recommend looking at each commit individually.
Using `Ord` to accomplish a meaning of subset relationship
can be hard to read. The existing uses for that are easily
replaced with a `match`, and in my opinion, more readable
without needing to resorting to comments to explain the
intention.
Optimize `Symbol::integer` by utilizing in-place formatting
This PR optimize `Symbol::integer` by utilizing `itoa` in-place formatting instead of going through a dynamically allocated `String` and the format machinery.
<details>
For some context: I was profiling `rustc --check-cfg` with callgrind and due to the way we currently setup all the targets and we end-up calling `Symbol::integer` multiple times for all the targets. Using `itoa` reduced the number of instructions.
</details>
Lint singleton gaps after exclusive ranges
In the discussion to stabilize exclusive range patterns (https://github.com/rust-lang/rust/issues/37854), it has often come up that they're likely to cause off-by-one mistakes. We already have the `overlapping_range_endpoints` lint, so I [proposed](https://github.com/rust-lang/rust/issues/37854#issuecomment-1845580712) a lint to catch the complementary mistake.
This PR adds a new `non_contiguous_range_endpoints` lint that catches likely off-by-one errors with exclusive range patterns. Here's the idea (see the test file for more examples):
```rust
match x {
0..10 => ..., // WARN: this range doesn't match `10_u8` because `..` is an exclusive range
11..20 => ..., // this could appear to continue range `0_u8..10_u8`, but `10_u8` isn't matched by either of them
_ => ...,
}
// help: use an inclusive range instead: `0_u8..=10_u8`
```
More precisely: for any exclusive range `lo..hi`, if `hi+1` is matched by another range but `hi` isn't, we suggest writing an inclusive range `lo..=hi` instead. We also catch `lo..T::MAX`.
Avoid invoking the `intrinsic` query for DefKinds other than `Fn` or `AssocFn`
fixes the perf regression from https://github.com/rust-lang/rust/pull/120675 by only invoking (and thus inserting into the dep graph) the `intrinsic` query if the `DefKind` matches items that can actually be intrinsics
Subtree sync for rustc_codegen_cranelift
The main highlight this time is a bunch of new vendor intrinsics. Cranelift has also been updated to 0.105. And there were a bunch of big-endian fixes.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Don't ICE if we collect no RPITITs unless there are no unification errors
Move an assertion in `collect_return_position_impl_trait_in_trait_tys` to after the `ObligationCtxt::eq` calls, so that we only assert and ICE if we have unification errors.
Fixes#121468
Fix misaligned loads when loading UEFI arg pointers
Currently, the two UEFI argument pointers are stored in an `alloca` of alignment 1, a pointer to which is then passed as `argv`. However, [the library code](9c3ad802d9/library/std/src/sys/pal/uefi/mod.rs (L60-L61)) treats `argv` as a pointer to an array of pointers and dereferences it as such, meaning that it presumes the `alloca` is aligned to at least the alignment of a pointer. This PR fixes this mismatch by aligning the `alloca` to the alignment of a pointer.
This PR also changed the `gep` to use the new `inbounds_ptradd` method.
Add the new description field to Target::to_json, and add descriptions for some MSVC targets
The original PR to add a `description` field to `Target` (<https://github.com/rust-lang/rust/pull/121905>) didn't add the field to `Target::to_json`, which meant that the `check_consistency` testwould fail if you tried to set a description as it wouldn't survive round-tripping via JSON: https://github.com/rust-lang/rust/actions/runs/8180997936/job/22370052535#step:27:4967
This change adds the field to `Target::to_json`, and sets some descriptions to verify that it works correctly.
Tweak the way we protect in-place function arguments in interpreters
Use `MPlaceTy` instead of `PlaceTy` in `FnArg` and ignore (copy) locals in an earlier step ("Locals that don't have their address taken are as protected as they can ever be").
This seems to be crucial for tail call support (as they can't refer to caller's locals which are killed when replacing the stack frame).
r? `@RalfJung`
cc `@oli-obk`
see https://github.com/rust-lang/rust/pull/121273#issuecomment-1980210690
