Fix suggestion spans inside macros for the `unused_must_use` lint
This PR fixes the suggestion spans inside macros for the `unused_must_use` lint by trying to find the oldest ancestor span.
Fixes https://github.com/rust-lang/rust/issues/143025
`tests/ui`: A New Order [12/N]
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@jieyouxu`
Add SIMD funnel shift and round-to-even intrinsics
This PR adds 3 new SIMD intrinsics
- `simd_funnel_shl` - funnel shift left
- `simd_funnel_shr` - funnel shift right
- `simd_round_ties_even` (vector version of `round_ties_even_fN`)
TODO (future PR): implement `simd_fsh{l,r}` in miri, cg_gcc and cg_clif (it is surprisingly hard to implement without branches, the common tricks that rotate uses doesn't work because we have 2 elements now. e.g, the `-n&31` trick used by cg_gcc to implement rotate doesn't work with this because then `fshl(a, b, 0)` will be `a | b`)
[#t-compiler > More SIMD intrinsics](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/More.20SIMD.20intrinsics/with/522130286)
`@rustbot` label T-compiler T-libs A-intrinsics F-core_intrinsics
r? `@workingjubilee`
Add regression test for #137857 to ensure that we generate intra doc links for extern crate items.
Fixes https://github.com/rust-lang/rust/issues/137857.
I checked that linking to extern crates was generating valid links (with the `/index.html` part) and since it's already working, just adding a regression test.
r? `@notriddle`
rustdoc: show attributes on enum variants
mostly for #[non_exhaustive]
unsure if there's any attributes we should take care to *not* include, it could use `render_code_attribute` and `is_non_exhaustive` instead, if that is a concern.
fixesrust-lang/rust#142599
Insert checks for enum discriminants when debug assertions are enabled
Similar to the existing null-pointer and alignment checks, this checks for valid enum discriminants on creation of enums through unsafe transmutes. Essentially this sanitizes patterns like the following:
```rust
let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) };
```
An extension of this check will be done in a follow-up that explicitly sanitizes for extern enum values that come into Rust from e.g. C/C++.
This check is similar to Miri's capabilities of checking for valid construction of enum values.
This PR is inspired by saethlin@'s PR
https://github.com/rust-lang/rust/pull/104862. Thank you so much for keeping this code up and the detailed comments!
I also pair-programmed large parts of this together with vabr-g@.
r? `@saethlin`
gce: don't ICE on non-local const
Fixesrust-lang/rust#133808
I have absolutely no idea what I'm doing here, but I followed `@BoxyUwU` 's [instructions](https://github.com/rust-lang/rust/issues/133808#issuecomment-3009122957), and turns out this small change fixesrust-lang/rust#133808, and doesn't seem to break anything else.
(This code path is only reachable when the GCE feature gate is enabled, so even if it does break in a way that is not caught by current test coverage, I guess it's not as bad as breaking stable or non-incomplete features?)
Anyways, r? `@BoxyUwU` , if you don't mind.
hir_analysis: prohibit `dyn PointeeSized`
Fixesrust-lang/rust#142652
Supersedes rust-lang/rust#142663
`dyn PointeeSized` is nonsensical as a `dyn PointeeSized` needs to be `MetaSized`, so lets reject it to avoid hitting code paths that expect a builtin impl for `PointeeSized`
r? `@compiler-errors`
const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology
This error recently got changed in https://github.com/rust-lang/rust/pull/140942 to use the terminology of "top-level scope", but after further discussion in https://github.com/rust-lang/reference/pull/1865 it seems the reference will not be using that terminology after all. So let's also remove it from the compiler again, and let's focus on what actually happens with these temporaries: their lifetime is extended until the end of the program.
r? ``@oli-obk`` ``@traviscross``
Normalize before computing ConstArgHasType goal in new solver
This is a fix for rust-lang/rust#139905. See the description I left in the test.
I chose to fix this by normalizing the type before matching on its `.kind()` in `compute_const_arg_has_type_goal` (since it feels somewhat consistent with how we normalize types before assembling their candidates, for example); however, there are several other solutions that come to mind for fixing this ICE:
1. (this solution)
2. Giving `ConstKind::Error` a proper type, like `ConstKind::Value`, so that consts don't go from failing to passing `ConstArgHasType` goals after normalization (i.e. `UNEVALUATED` would normalize into a `ConstKind::Error(_, bool)` type rather than losing its type altogether).
3. Just suppressing the errors and accepting the fact that goals can go from fail->pass after normalization.
Thoughts? Happy to discuss this fix further.
r? `@BoxyUwU`
suggest declaring modules when file found but module not defined
suggests declaring modules when a module is found but not defined, i.e
```
├── main.rs: `use thing::thang;`
└── thing.rs: `struct thang`
```
or
```
├── main.rs: `use thing::thang;`
└── thing
└── mod.rs: `struct thang`
```
which currently is just
```rust
error[E0432]: unresolved import `yeah`
--> src/main.rs:1:1
|
1 | use thing::thang;
| ^^^^^ use of unresolved module or unlinked crate `thing`
|
```
but now would have this nice help:
```text
= help: you may have forgotten to declare the module `thing`. use `mod thing` in this file to declare this module.
```
New const traits syntax
This PR only affects the AST and doesn't actually change anything semantically.
All occurrences of `~const` outside of libcore have been replaced by `[const]`. Within libcore we have to wait for rustfmt to be bumped in the bootstrap compiler. This will happen "automatically" (when rustfmt is run) during the bootstrap bump, as rustfmt converts `~const` into `[const]`. After this we can remove the `~const` support from the parser
Caveat discovered during impl: there is no legacy bare trait object recovery for `[const] Trait` as that snippet in type position goes down the slice /array parsing code and will error
r? ``@fee1-dead``
cc ``@nikomatsakis`` ``@traviscross`` ``@compiler-errors``
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#142270 (Rustdoc js: even more typechecking improvements)
- rust-lang/rust#142420 (Report infer ty errors during hir ty lowering)
- rust-lang/rust#142671 (add #![rustc_no_implicit_bounds])
- rust-lang/rust#142721 (Add tracing to `InterpCx::layout_of()` )
- rust-lang/rust#142818 (Port `#[used]` to new attribute parsing infrastructure)
- rust-lang/rust#143020 (codegen_fn_attrs: make comment more precise)
- rust-lang/rust#143051 (Add tracing to `validate_operand`)
- rust-lang/rust#143060 (Only args in main diag are saved and restored without removing the newly added ones)
- rust-lang/rust#143065 (Improve recovery when users write `where:`)
- rust-lang/rust#143084 (const-eval: error when initializing a static writes to that static)
r? `@ghost`
`@rustbot` modify labels: rollup
const-eval: error when initializing a static writes to that static
Fixes https://github.com/rust-lang/rust/issues/142404 by also calling the relevant hook for writes, not just reads. To avoid erroring during the actual write of the initial value, we neuter the hook when popping the final stack frame.
Calling the hook during writes requires changing its signature since we cannot pass in the entire interpreter any more.
While doing this I also realized a gap in https://github.com/rust-lang/rust/pull/142575 for zero-sized copies on the read side, so I fixed that and added a test.
r? `@oli-obk`
Improve recovery when users write `where:`
Improve recovery of `where:`.
Fixes https://github.com/rust-lang/rust/issues/143023
The erroneous suggestion was because we were seeing `:` then a type, which the original impl thought must be a struct field. Make this a bit more accurate by checking for a non-reserved ident (which should be a field name).
Also, make a custom parser error for `where:` so we can continue parsing after the colon.
add #![rustc_no_implicit_bounds]
Follow-up from rust-lang/rust#137944.
Adds a new `rustc_attrs` attribute that stops rustc from adding any default bounds. Useful for tests where default bounds just add noise and make debugging harder.
After reviewing all tests with `?Sized`, these tests seem like they could probably benefit from `#![rustc_no_implicit_bounds]`.
- Skipping most of `tests/ui/unsized` as these seem to want to test `?Sized`
- Skipping tests that used `Box<T>` because it's still bound by `T: MetaSized`
- Skipping parsing or other tests that cared about `?Sized` syntactically
- Skipping tests for `derive(CoercePointee)` because this appears to check that the pointee type is relaxed with `?Sized` explicitly
r? `@lcnr`
Stop collecting unmentioned constants
This avoids generating useless dead LLVM IR. This appears to have regressed and/or been introduced in rust-lang/rust#53821 (unfortunately a very large PR - I don't see any direct discussion there of this particular change), but as far as I can tell is at least no longer necessary -- or we lack test coverage -- because none of our UI tests indicate diagnostics regressions. The adjusted codegen-units test has comments explicitly noting that these items should *not* be collected ("These are not referenced, so they do not produce mono-items").
I noticed this while looking at libcore LLVM IR we generate, which contained dead code references to the NOOP Waker item, which is never used inside libcore. Producing LLVM IR for it during libcore's compilation, only for that IR to get deleted by LLVM as unused, isn't useful. Note that the IR is generally all marked internal, too.
Similar to the existing nullpointer and alignment checks, this checks
for valid enum discriminants on creation of enums through unsafe
transmutes. Essentially this sanitizes patterns like the following:
```rust
let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) };
```
An extension of this check will be done in a follow-up that explicitly
sanitizes for extern enum values that come into Rust from e.g. C/C++.
This check is similar to Miri's capabilities of checking for valid
construction of enum values.
This PR is inspired by saethlin@'s PR
https://github.com/rust-lang/rust/pull/104862. Thank you so much for
keeping this code up and the detailed comments!
I also pair-programmed large parts of this together with vabr-g@.
This centralizes the placeholder type error reporting in one location, but it also exposes the granularity at which we convert things from hir to ty more. E.g. previously infer types in where bounds were errored together with the function signature, but now they are independent.
After reviewing all tests with `?Sized` and discussing with lcnr, these
tests seem like they could probably benefit from
`#![rustc_no_implicit_bounds]`.
Move an ACE test out of the GCI directory
In https://github.com/rust-lang/rust/pull/122988, a test pertaining to `associated_const_equality` was placed into the directory meant for `generic_const_items`. Let's move it where it belongs.
While at it, I took the time to further minimize the test and to add a description. You can use 1.67.1 (as reported in rust-lang/rust#108220) to verify that I didn't butcher it. For additional context, the issue was likely fixed in rust-lang/rust#112718 (but I'm also cc'ing rust-lang/rust#140467 which further fixed things up and has more context).
I only performed quick and dirty git/GitHub archeology, so I don't have the full picture here. For one, I'm not even sure if this regression test is worth it.
Anyway, I just want it gone from the GCI dir :)
Port `#[export_name]` to the new attribute parsing infrastructure
This PR contains two changes, in separate commits for reviewability:
- Ports `export_name` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
- Moves the check for mixing export_name/no_mangle to check_attr.rs and improve the error message, which previously had a mix of 2021/2024 edition syntax
r? ``@jdonszelmann``
[perf] Compute hard errors without diagnostics in impl_intersection_has_impossible_obligation
First compute hard errors without diagnostics, then ambiguities with diagnostics since we need to know if any of them overflowed.
const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns
This fixes https://github.com/rust-lang/rust/issues/140653 by accepting code such as this:
```rust
static FOO: AtomicU32 = AtomicU32::new(0);
const C: &'static AtomicU32 = &FOO;
```
This can be written entirely in safe code, so there can't really be anything wrong with it.
We also accept the much more questionable following code, since it looks very similar to the interpreter:
```rust
static mut FOO2: u32 = 0;
const C2: &'static u32 = unsafe { &mut FOO2 };
```
Using this without causing UB is at least very hard (the details are unclear since it is related to how the aliasing model deals with the staging of const-eval vs runtime code).
If a constant like `C2` is used as a pattern, we emit an error:
```
error: constant BAD_PATTERN cannot be used as pattern
--> $DIR/const_refs_to_static_fail.rs:30:9
|
LL | BAD_PATTERN => {},
| ^^^^^^^^^^^
|
= note: constants that reference mutable or external memory cannot be used as pattern
```
(If you somehow manage to build a pattern with constant `C`, you'd get the same error, but that should be impossible: we don't have a type that can be used in patterns and that has interior mutability.)
The same treatment is afforded for shared references to `extern static`, for the same reason: the const evaluation is entirely fine with it, we just can't build a pattern for it -- and when using interior mutability, this can be totally sound.
We do still not accept anything where there is an `&mut` in the final value of the const, as that should always require unsafe code and it's hard to imagine a sound use-case that would require this.
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#124595 (Suggest cloning `Arc` moved into closure)
- rust-lang/rust#139594 (Simplify `ObligationCauseCode::IfExpression`)
- rust-lang/rust#141311 (make `tidy-alphabetical` use a natural sort)
- rust-lang/rust#141648 ([rustdoc] Do not emit redundant_explicit_links lint if the doc comment comes from expansion)
- rust-lang/rust#142285 (tests: Do not run afoul of asm.validity.non-exhaustive in input-stats)
- rust-lang/rust#142393 (Don't give APITs names with macro expansion placeholder fragments in it)
- rust-lang/rust#142884 (StableMIR: Add method to retrieve body of coroutine)
- rust-lang/rust#142981 (Make missing lifetime suggestion verbose)
r? `@ghost`
`@rustbot` modify labels: rollup
