about summary refs log tree commit diff
path: root/tests
AgeCommit message (Collapse)AuthorLines
2025-06-30Remove the nullary intrinsic const eval logic and treat them like other ↵Oli Scherer-1/+1
intrinsics
2025-06-30Stop backends from needing to support nullary intrinsicsOli Scherer-37/+23
2025-06-29Rollup merge of #143030 - Urgau:issue-143025, r=SparrowLiiGuillaume Gomez-1/+172
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
2025-06-29Rollup merge of #142417 - Kivooeo:tf12, r=jieyouxuGuillaume Gomez-145/+162
`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`
2025-06-29Rollup merge of #142214 - Kivooeo:tf9, r=jieyouxuGuillaume Gomez-74/+83
`tests/ui`: A New Order [9/N] Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
2025-06-29Rollup merge of #142078 - sayantn:more-intrinsics, r=workingjubileeGuillaume Gomez-25/+138
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`
2025-06-29Rollup merge of #143171 - fmease:fix-span-of-maybe-const-mod, r=compiler-errorsMatthias Krüger-267/+267
Fix the span of trait bound modifier `[const]` r? project-const-traits or anyone
2025-06-29Rollup merge of #143138 - JonathanBrouwer:link_name_parser, r=jdonszelmannMatthias Krüger-46/+29
Port `#[link_name]` to the new attribute parsing infrastructure Ports `link_name` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197 r? `@jdonszelmann`
2025-06-29Rollup merge of #142641 - bjorn3:proc_macro_symbols_o, r=jieyouxuMatthias Krüger-0/+25
Generate symbols.o for proc-macros too To ensure used statics are functioning correctly for proc-macros too.
2025-06-29Rollup merge of #142367 - GuillaumeGomez:extern-crate-items-intra-doc, ↵Matthias Krüger-0/+23
r=lolbinarycat 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`
2025-06-29Fix the span of trait bound modifier `[const]`León Orell Valerian Liehr-267/+267
2025-06-28Rollup merge of #142987 - lolbinarycat:rustdoc-non_exhaustive-enum-v-142599, ↵Matthias Krüger-0/+25
r=GuillaumeGomez 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. fixes rust-lang/rust#142599
2025-06-28cleaned up some testsKivooeo-74/+83
2025-06-28Port `#[link_name]` to the new attribute parsing infrastructureJonathan Brouwer-46/+29
Co-authored-by: Anne Stijns <anstijns@gmail.com> Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-06-28cleaned up some testsKivooeo-145/+162
2025-06-28Auto merge of #141759 - 1c3t3a:discriminants-query, r=saethlinbors-0/+339
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`
2025-06-28Add regression test for #137857 to ensure that we generate intra doc links ↵Guillaume Gomez-0/+23
for extern crate items.
2025-06-27Rollup merge of #143106 - yotamofek:pr/gce/non-local-ice, r=BoxyUwUMatthias Krüger-15/+20
gce: don't ICE on non-local const Fixes rust-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 fixes rust-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.
2025-06-27Rollup merge of #143104 - davidtwco:issue-142652-dyn-pointeesized-deny, ↵Matthias Krüger-0/+30
r=compiler-errors hir_analysis: prohibit `dyn PointeeSized` Fixes rust-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`
2025-06-27Rollup merge of #143092 - RalfJung:const-check-lifetime-ext, r=oli-obkMatthias Krüger-75/+171
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``
2025-06-27Rollup merge of #143046 - RalfJung:zst-unsafe-cell, r=lcnr,oli-obkMatthias Krüger-0/+15
const validation: properly ignore zero-sized UnsafeCell Fixes https://github.com/rust-lang/rust/issues/142948 r? `@oli-obk`
2025-06-27Rollup merge of #142806 - compiler-errors:norm-ct-has-ty, r=lcnr,BoxyUwUMatthias Krüger-0/+28
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`
2025-06-27Rollup merge of #142730 - ↵Matthias Krüger-1/+68
bend-n:suggest_declaring_modules_when_file_found_but_module_not_defined, r=petrochenkov 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. ```
2025-06-27Rollup merge of #140809 - bjorn3:panic_runtime_cleanup, r=petrochenkovMatthias Krüger-25/+3
Reduce special casing for the panic runtime See the individual commits for more info.
2025-06-27Rollup merge of #139858 - oli-obk:new-const-traits-syntax, r=fee1-deadMatthias Krüger-1440/+1493
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``
2025-06-27gce: don't ICE on non-local constYotam Ofek-15/+20
2025-06-27hir_analysis: prohibit `dyn PointeeSized`David Wood-0/+30
2025-06-27Auto merge of #143091 - GuillaumeGomez:rollup-f300qwe, r=GuillaumeGomezbors-666/+617
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
2025-06-27const checks: avoid 'top-level scope' terminologyRalf Jung-75/+171
2025-06-27Rollup merge of #143084 - RalfJung:const-eval-recursive-static-write, r=oli-obkGuillaume Gomez-30/+92
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`
2025-06-27Rollup merge of #143065 - compiler-errors:enum-recovery, r=oli-obkGuillaume Gomez-0/+23
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.
2025-06-27Rollup merge of #142818 - JonathanBrouwer:used_new_parser, r=jdonszelmannGuillaume Gomez-25/+71
Port `#[used]` to new attribute parsing infrastructure Ports `used` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197 r? ``@jdonszelmann``
2025-06-27Rollup merge of #142671 - davidtwco:no-default-bounds-attr, r=lcnrGuillaume Gomez-89/+109
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`
2025-06-27Auto merge of #142893 - Mark-Simulacrum:no-const-collect, r=oli-obkbors-5/+0
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.
2025-06-27const-eval: error when initializing a static writes to that staticRalf Jung-30/+92
2025-06-27Generate symbols.o for proc-macros toobjorn3-0/+25
To ensure used statics are functioning correctly for proc-macros too.
2025-06-27Insert checks for enum discriminants when debug assertions are enabledBastian Kersting-0/+339
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@.
2025-06-27Report infer ty errors during hir ty loweringOli Scherer-522/+322
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.
2025-06-27Port `#[used]` to new attribute parsing infrastructureJonathan Brouwer-25/+71
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-06-27tests: add #![rustc_no_implicit_bounds]David Wood-89/+109
After reviewing all tests with `?Sized` and discussing with lcnr, these tests seem like they could probably benefit from `#![rustc_no_implicit_bounds]`.
2025-06-27testsbendn-0/+64
2025-06-27Auto merge of #143074 - compiler-errors:rollup-cv64hdh, r=compiler-errorsbors-260/+352
Rollup of 18 pull requests Successful merges: - rust-lang/rust#137843 (make RefCell unstably const) - rust-lang/rust#140942 (const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns) - rust-lang/rust#142549 (small iter.intersperse.fold() optimization) - rust-lang/rust#142637 (Remove some glob imports from the type system) - rust-lang/rust#142647 ([perf] Compute hard errors without diagnostics in impl_intersection_has_impossible_obligation) - rust-lang/rust#142700 (Remove incorrect comments in `Weak`) - rust-lang/rust#142927 (Add note to `find_const_ty_from_env`) - rust-lang/rust#142967 (Fix RwLock::try_write documentation for WouldBlock condition) - rust-lang/rust#142986 (Port `#[export_name]` to the new attribute parsing infrastructure) - rust-lang/rust#143001 (Rename run always ) - rust-lang/rust#143010 (Update `browser-ui-test` version to `0.20.7`) - rust-lang/rust#143015 (Add `sym::macro_pin` diagnostic item for `core::pin::pin!()`) - rust-lang/rust#143033 (Expand const-stabilized API links in relnotes) - rust-lang/rust#143041 (Remove cache for citool) - rust-lang/rust#143056 (Move an ACE test out of the GCI directory) - rust-lang/rust#143059 (Fix 1.88 relnotes) - rust-lang/rust#143067 (Tracking issue number for `iter_macro`) - rust-lang/rust#143073 (Fix some fixmes that were waiting for let chains) Failed merges: - rust-lang/rust#143020 (codegen_fn_attrs: make comment more precise) r? `@ghost` `@rustbot` modify labels: rollup
2025-06-26Rollup merge of #143056 - fmease:mv-ace-test-out-of-gci-dir, r=BoxyUwUMichael Goulet-35/+17
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 :)
2025-06-26Rollup merge of #142986 - JonathanBrouwer:export_name_parser, r=jdonszelmannMichael Goulet-23/+94
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``
2025-06-26Rollup merge of #142647 - compiler-errors:less-work-in-coherence, r=lcnrMichael Goulet-6/+0
[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.
2025-06-26Rollup merge of #140942 - RalfJung:const-ref-to-mut, r=oli-obkMichael Goulet-196/+241
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.
2025-06-26Auto merge of #143057 - matthiaskrgr:rollup-bulih8o, r=matthiaskrgrbors-215/+612
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
2025-06-26Better recoveryMichael Goulet-6/+13
2025-06-26Make recovery for enum with struct field a bit more accurateMichael Goulet-0/+16
2025-06-26rustdoc: show attributes on enum variantsbinarycat-0/+25
mostly for #[non_exhaustive]