about summary refs log tree commit diff
path: root/tests
AgeCommit message (Collapse)AuthorLines
2025-04-21Rollup merge of #140076 - aDotInTheVoid:jsondocline, r=GuillaumeGomezChris Denton-1/+1
jsondocck: Require command is at start of line In one place we use `///``@``` instead of `//``@`.`` The test-runner allowed it, but it probably shouldn't. Ran into by ``@lolbinarycat`` in https://github.com/rust-lang/rust/pull/132748#issuecomment-2816469322: ``` error: unknown disambiguator `?(` ##[error] --> /checkout/tests/rustdoc-json/fns/return_type_alias.rs:3:25 | 3 | ///@ set foo = "$.index[?(``@.name=='Foo')].id"`` | ^^ | ``` Maybe it's also worth erroring on this like we added in #137103 r? ``@GuillaumeGomez``
2025-04-21Rollup merge of #140074 - aDotInTheVoid:auto-test, r=GuillaumeGomezChris Denton-2/+4
rustdoc-json: Improve test for auto-trait impls The TODO is fixable now due-to #138763. While I was here I realized there's probably a a few more things we should also test. r? ```@GuillaumeGomez```
2025-04-21Rollup merge of #140052 - GuillaumeGomez:fix-140026, r=nnethercoteChris Denton-0/+22
Fix error when an intra doc link is trying to resolve an empty associated item Fixes https://github.com/rust-lang/rust/issues/140026. Assigning ```@nnethercote``` since they're the one who wrote the initial change. I updated rustdoc code instead of compiler's because I think it makes more sense that the caller ensures on their side that the name they're looking for isn't empty. r? ```@nnethercote```
2025-04-21Rollup merge of #140036 - jieyouxu:ui-cleanup-4, r=compiler-errorsChris Denton-33/+76
Advent of `tests/ui` (misc cleanups and improvements) [4/N] Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of #133895. ### Review advice - Best reviewed commit-by-commit. - I can squash commits before merge, commits are separate to make it easier to review.
2025-04-21Rollup merge of #134213 - folkertdev:stabilize-naked-functions, ↵Chris Denton-264/+160
r=tgross35,Amanieu,traviscross Stabilize `naked_functions` tracking issue: https://github.com/rust-lang/rust/issues/90957 request for stabilization on tracking issue: https://github.com/rust-lang/rust/issues/90957#issuecomment-2539270352 reference PR: https://github.com/rust-lang/reference/pull/1689 # Request for Stabilization Two years later, we're ready to try this again. Even though this issue is already marked as having passed FCP, given the amount of time that has passed and the changes in implementation strategy, we should follow the process again. ## Summary The `naked_functions` feature has two main parts: the `#[naked]` function attribute, and the `naked_asm!` macro. An example of a naked function: ```rust const THREE: usize = 3; #[naked] pub extern "sysv64" fn add_n(number: usize) -> usize { // SAFETY: the validity of the used registers // is guaranteed according to the "sysv64" ABI unsafe { core::arch::naked_asm!( "add rdi, {}", "mov rax, rdi", "ret", const THREE, ) } } ``` When the `#[naked]` attribute is applied to a function, the compiler won't emit a [function prologue](https://en.wikipedia.org/wiki/Function_prologue_and_epilogue) or epilogue when generating code for this function. This attribute is analogous to [`__attribute__((naked))`](https://developer.arm.com/documentation/100067/0608/Compiler-specific-Function--Variable--and-Type-Attributes/--attribute----naked---function-attribute) in C. The use of this feature allows the programmer to have precise control over the assembly that is generated for a given function. The body of a naked function must consist of a single `naked_asm!` invocation, a heavily restricted variant of the `asm!` macro: the only legal operands are `const` and `sym`, and the only legal options are `raw` and `att_syntax`. In lieu of specifying operands, the `naked_asm!` within a naked function relies on the function's calling convention to determine the validity of registers. ## Documentation The Rust Reference: https://github.com/rust-lang/reference/pull/1689 (Previous PR: https://github.com/rust-lang/reference/pull/1153) ## Tests * [tests/run-make/naked-symbol-visiblity](https://github.com/rust-lang/rust/tree/master/tests/codegen/naked-fn) verifies that `pub`, `#[no_mangle]` and `#[linkage = "..."]` work correctly for naked functions * [tests/codegen/naked-fn](https://github.com/rust-lang/rust/tree/master/tests/codegen/naked-fn) has tests for function alignment, use of generics, and validates the exact assembly output on linux, macos, windows and thumb * [tests/ui/asm/naked-*](https://github.com/rust-lang/rust/tree/master/tests/ui/asm) tests for incompatible attributes, generating errors around incorrect use of `naked_asm!`, etc ## Interaction with other (unstable) features ### [fn_align](https://github.com/rust-lang/rust/issues/82232) Combining `#[naked]` with `#[repr(align(N))]` works well, and is tested e.g. here - https://github.com/rust-lang/rust/blob/master/tests/codegen/naked-fn/aligned.rs - https://github.com/rust-lang/rust/blob/master/tests/codegen/naked-fn/min-function-alignment.rs It's tested extensively because we do need to explicitly support the `repr(align)` attribute (and make sure we e.g. don't mistake powers of two for number of bytes). ## History This feature was originally proposed in [RFC 1201](https://github.com/rust-lang/rfcs/pull/1201), filed on 2015-07-10 and accepted on 2016-03-21. Support for this feature was added in [#32410](https://github.com/rust-lang/rust/pull/32410), landing on 2016-03-23. Development languished for several years as it was realized that the semantics given in RFC 1201 were insufficiently specific. To address this, a minimal subset of naked functions was specified by [RFC 2972](https://github.com/rust-lang/rfcs/pull/2972), filed on 2020-08-07 and accepted on 2021-11-16. Prior to the acceptance of RFC 2972, all of the stricter behavior specified by RFC 2972 was implemented as a series of warn-by-default lints that would trigger on existing uses of the `naked` attribute; these lints became hard errors in [#93153](https://github.com/rust-lang/rust/pull/93153) on 2022-01-22. As a result, today RFC 2972 has completely superseded RFC 1201 in describing the semantics of the `naked` attribute. More recently, the `naked_asm!` macro was added to replace the earlier use of a heavily restricted `asm!` invocation. The `naked_asm!` name is clearer in error messages, and provides a place for documenting the specific requirements of inline assembly in naked functions. The implementation strategy was changed to emitting a global assembly block. In effect, an extern function ```rust extern "C" fn foo() { core::arch::naked_asm!("ret") } ``` is emitted as something similar to ```rust core::arch::global_asm!( "foo:", "ret" ); extern "C" { fn foo(); } ``` The codegen approach was chosen over the llvm naked function attribute because: - the rust compiler can guarantee the behavior (no sneaky additional instructions, no inlining, etc.) - behavior is the same on all backends (llvm, cranelift, gcc, etc) Finally, there is now an allow list of compatible attributes on naked functions, so that e.g. `#[inline]` is rejected with an error. The `#[target_feature]` attribute on naked functions was later made separately unstable, because implementing it is complex and we did not want to block naked functions themselves on how target features work on them. See also https://github.com/rust-lang/rust/issues/138568. relevant PRs for these recent changes - https://github.com/rust-lang/rust/pull/127853 - https://github.com/rust-lang/rust/pull/128651 - https://github.com/rust-lang/rust/pull/128004 - https://github.com/rust-lang/rust/pull/138570 - ### Various historical notes #### `noreturn` [RFC 2972](https://github.com/rust-lang/rfcs/blob/master/text/2972-constrained-naked.md) mentions that naked functions > must have a body which contains only a single asm!() statement which: > iii. must contain the noreturn option. Instead of `asm!`, the current implementation mandates that the body contain a single `naked_asm!` statement. The `naked_asm!` macro is a heavily restricted version of the `asm!` macro, making it easier to talk about and document the rules of assembly in naked functions and give dedicated error messages. For `naked_asm!`, the behavior of the `asm!`'s `noreturn` option is implicit. The `noreturn` option means that it is UB for control flow to fall through the end of the assembly block. With `asm!`, this option is usually used for blocks that diverge (and thus have no return and can be typed as `!`). With `naked_asm!`, the intent is different: usually naked funtions do return, but they must do so from within the assembly block. The `noreturn` option was used so that the compiler would not itself also insert a `ret` instruction at the very end. #### padding / `ud2` A `naked_asm!` block that violates the safety assumption that control flow must not fall through the end of the assembly block is UB. Because no return instruction is emitted, whatever bytes follow the naked function will be executed, resulting in truly undefined behavior. There has been discussion whether rustc should emit an invalid instruction (e.g. `ud2` on x86) after the `naked_asm!` block to at least fail early in the case of an invalid `naked_asm!`. It was however decided that it is more useful to guarantee that `#[naked]` functions NEVER contain any instructions besides those in the `naked_asm!` block. # unresolved questions None r? ``@Amanieu`` I've validated the tests on x86_64 and aarch64
2025-04-20Rollup merge of #137953 - RalfJung:simd-intrinsic-masks, r=WaffleLapkinChris Denton-58/+83
simd intrinsics with mask: accept unsigned integer masks, and fix some of the errors It's not clear at all why the mask would have to be signed, it is anyway interpreted bitwise. The backend should just make sure that works no matter the surface-level type; our LLVM backend already does this correctly. The note of "the mask may be widened, which only has the correct behavior for signed integers" explains... nothing? Why can't the code do the widening correctly? If necessary, just cast to the signed type first... Also while we are at it, fix the errors. For simd_masked_load/store, the errors talked about the "third argument" but they meant the first argument (the mask is the first argument there). They also used the wrong type for `expected_element`. I have extremely low confidence in the GCC part of this PR. See [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/257879-project-portable-simd/topic/On.20the.20sign.20of.20masks)
2025-04-20jsondocck: Require command is at start of lineAlona Enraght-Moony-1/+1
2025-04-20rustdoc-json: Improve test for auto-trait implsAlona Enraght-Moony-2/+4
2025-04-20simd intrinsics with mask: accept unsigned integer masksRalf Jung-58/+83
2025-04-20stabilize `naked_functions`Folkert de Vries-264/+160
2025-04-20Auto merge of #140043 - ChrisDenton:rollup-vwf0s9j, r=ChrisDentonbors-871/+805
Rollup of 8 pull requests Successful merges: - #138934 (support config extensions) - #139091 (Rewrite on_unimplemented format string parser.) - #139753 (Make `#[naked]` an unsafe attribute) - #139762 (Don't assemble non-env/bound candidates if projection is rigid) - #139834 (Don't canonicalize crate paths) - #139868 (Move `pal::env` to `std::sys::env_consts`) - #139978 (Add citool command for generating a test dashboard) - #139995 (Clean UI tests 4 of n) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-19Rollup merge of #139042 - compiler-errors:do-not-optimize-switchint, r=saethlinChris Denton-31/+131
Do not remove trivial `SwitchInt` in analysis MIR This PR ensures that we don't prematurely remove trivial `SwitchInt` terminators which affects both the borrow-checking and runtime semantics (i.e. UB) of the code. Previously the `SimplifyCfg` optimization was removing `SwitchInt` terminators when they was "trivial", i.e. when all arms branched to the same basic block, even if that `SwitchInt` terminator had the side-effect of reading an operand which (for example) may not be initialized or may point to an invalid place in memory. This behavior is unlike all other optimizations, which are only applied after "analysis" (i.e. borrow-checking) is finished, and which Miri disables to make sure the compiler doesn't silently remove UB. Fixing this code "breaks" (i.e. unmasks) code that used to borrow-check but no longer does, like: ```rust fn foo() { let x; let (0 | _) = x; } ``` This match expression should perform a read because `_` does not shadow the `0` literal pattern, and the compiler should have to read the match scrutinee to compare it to 0. I've checked that this behavior does not actually manifest in practice via a crater run which came back clean: https://github.com/rust-lang/rust/pull/139042#issuecomment-2767436367 As a side-note, it may be tempting to suggest that this is actually a good thing or that we should preserve this behavior. If we wanted to make this work (i.e. trivially optimize out reads from matches that are redundant like `0 | _`), then we should be enabling this behavior *after* fixing this. However, I think it's kinda unprincipled, and for example other variations of the code don't even work today, e.g.: ```rust fn foo() { let x; let (0.. | _) = x; } ```
2025-04-19Add regression test for #140026Guillaume Gomez-0/+22
2025-04-19Rollup merge of #139995 - spencer3035:clean-ui-tests-4-of-n, r=jieyouxuChris Denton-176/+201
Clean UI tests 4 of n Cleaned up some tests that have `issue` in the title. I kept the commits to be one per "`issue`" cleanup/rename to make it easier to check. I can rebase to one commit once the changes are approved. Related Issues: #73494 #133895 r? jieyouxu
2025-04-19Rollup merge of #139834 - ChrisDenton:spf, r=WaffleLapkinChris Denton-0/+61
Don't canonicalize crate paths When printing paths in diagnostic we should favour printing the paths that were passed in rather than resolving all symlinks. This PR changes the form of the crate path but it should only really affect diagnostics as filesystem functions won't care which path is used. The uncanonicalized path was already used as a fallback for when canonicalization failed. This is a partial alternative to #139823.
2025-04-19Rollup merge of #139762 - compiler-errors:non-env, r=lcnrChris Denton-17/+49
Don't assemble non-env/bound candidates if projection is rigid Putting this up for an initial review, it's still missing comments, clean-up, and possibly a tweak to deal with ambiguities in the `BestObligation` folder. This PR fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/173. Specifically, we're creating an unnecessary query cycle in normalization by assembling an *impl candidate* even if we know later on during `merge_candidates` that we'll be filtering out that impl candidate. This PR adjusts the `merge_candidates` to assemble *only* env/bound candidates if we have `TraitGoalProvenVia::ParamEnv | TraitGoalProvenVia::AliasBound`. I'll leave some thoughts/comments in the code. r? lcnr
2025-04-19Rollup merge of #139753 - folkertdev:naked-function-unsafe-attribute, ↵Chris Denton-362/+341
r=tgross35,traviscross Make `#[naked]` an unsafe attribute tracking issue: https://github.com/rust-lang/rust/issues/138997 Per https://github.com/rust-lang/rust/pull/134213#issuecomment-2755984503, the `#[naked]` attribute is now an unsafe attribute (in any edition). This can only be merged when the above PRs are merged, I'd just like to see if there are any CI surprises here, and maybe there is early review feedback too. r? ``@traviscross``
2025-04-19Rollup merge of #139091 - mejrs:format, r=compiler-errorsChris Denton-316/+153
Rewrite on_unimplemented format string parser. This PR rewrites the format string parser for `rustc_on_unimplemented` and `diagnostic::on_unimplemented`. I plan on moving this code (and more) into the new attribute parsing system soon and wanted to PR it separately. This PR introduces some minor differences though: - `rustc_on_unimplemented` on trait *implementations* is no longer checked/used - this is actually never used (outside of some tests) so I plan on removing it in the future. - for `rustc_on_unimplemented`, it introduces the `{This}` argument in favor of `{ThisTraitname}` (to be removed later). It'll be easier to parse. - for `rustc_on_unimplemented`, `Self` can now consistently be used as a filter, rather than just `_Self`. It used to not match correctly on for example `Self = "[{integer}]"` - Some error messages now have better spans. Fixes https://github.com/rust-lang/rust/issues/130627
2025-04-19Rollup merge of #139919 - GuillaumeGomez:rustdoc-json-1-indexed, r=aDotInTheVoidChris Denton-2/+6
Make rustdoc JSON Span column 1-based, just like line numbers Fixes https://github.com/rust-lang/rust/issues/139906. This PR does two things: 1. It makes column 1-indexed as well, just like lines. 2. It updates documentation about them to mention that they are 1-indexed. I think it's better for coherency to have them both 1-indexed instead of the weird mix we used to have. Docs for `line` and `col` fields can be found [here](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Loc.html#structfield.line). And finally: it adds a regression test to ensure they are indeed 1-indexed. r? `@aDotInTheVoid`
2025-04-19Rollup merge of #137454 - mu001999-contrib:fix-137414, r=wesleywiserChris Denton-0/+11
not lint break with label and unsafe block fixes #137414 we can't label unsafe blocks, so that we can do not lint them
2025-04-19tests: adjust `tests/ui/auto-instantiate.rs`Jieyou Xu-13/+28
- Reformat the test. - Document test intention. - Move test under `tests/ui/inference/`.
2025-04-19tests: adjust some `augmented-assignment*` testsJieyou Xu-2/+7
- `tests/ui/augmented-assignment-feature-gate-cross.rs`: - This was *originally* to feature-gate overloaded OpAssign cross-crate, but now let's keep it as a smoke test. - Renamed as `augmented-assignment-cross-crate.rs`. - Relocated under `tests/ui/binop/`. - `tests/ui/augmented-assignments.rs`: - Documented test intent. - Moved under `tests/ui/borrowck/`. - `tests/ui/augmented-assignment-rpass.rs`: - Renamed to drop the `-rpass` suffix, since this was leftover from when `run-pass` test suite was a thing. - Moved under `tests/ui/binop/`.
2025-04-19tests: rework `amdgpu-require-explicit-cpu.rs`Jieyou Xu-18/+41
- Reworked the test as a *centralized* version of checking that certain targets correctly require `-C target-cpu` being specified. - Document test intention. - Move `amdgpu-require-explicit-cpu.rs` under new dir `tests/ui/target-cpu/` - No other ui subdir really fits this "requires `-Ctarget-cpu`" check.
2025-04-19Auto merge of #139114 - m-ou-se:super-let-pin, r=davidtwcobors-81/+26
Implement `pin!()` using `super let` Tracking issue for super let: https://github.com/rust-lang/rust/issues/139076 This uses `super let` to implement `pin!()`. This means we can remove [the hack](https://github.com/rust-lang/rust/pull/138717) we had to put in to fix https://github.com/rust-lang/rust/issues/138596. It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field. While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable. It'd help [the experiment](https://github.com/rust-lang/rust/issues/139076) to have `pin!()` use `super let`, so we can get some more experience with it.
2025-04-19Cleaned up 4 tests in `tests/ui/issues`Spencer-176/+201
2025-04-19Make `#[naked]` an unsafe attributeFolkert de Vries-362/+341
2025-04-18Add regression test for span 1-indexed checkGuillaume Gomez-2/+6
2025-04-18Auto merge of #139996 - matthiaskrgr:rollup-0nka2hw, r=matthiaskrgrbors-23/+701
Rollup of 7 pull requests Successful merges: - #138528 (deref patterns: implement implicit deref patterns) - #139393 (rustdoc-json: Output target feature information) - #139553 (sync::mpsc: prevent double free on `Drop`) - #139615 (Remove `name_or_empty`) - #139853 (Disable combining LLD with external llvm-config) - #139913 (rustdoc/clean: Fix lowering of fn params (fixes correctness & HIR vs. middle parity regressions)) - #139942 (Ignore aix for tests/ui/erros/pic-linker.rs) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-18Rollup merge of #139989 - durin42:llvm-21-issue-101082, r=cuviperMatthias Krüger-10/+2
tests: adjust 101082 test for LLVM 21 fix Fixes #139987.
2025-04-18Rollup merge of #139976 - jieyouxu:plumbing, r=KobzolMatthias Krüger-4/+2
run-make: drop `os_pipe` workaround now that `anonymous_pipe` is stable on beta Follow-up to #137537 where I had to include a temporary dep on `os_pipe` before `anonymous_pipe` was stabilized. Now that `anonymous_pipe` is stable on beta, we can get rid of this workaround. Closes #137532. (Final cleanup item) r? `@Kobzol`
2025-04-18Rollup merge of #138599 - adwinwhite:recursive-overflow, r=wesleywiserMatthias Krüger-61/+16
avoid overflow when generating debuginfo for expanding recursive types Fixes #135093 Fixes #121538 Fixes #107362 Fixes #100618 Fixes #115994 The overflow happens because expanding recursive types keep creating new nested types when recurring into sub fields. I fixed that by returning an empty stub node when expanding recursion is detected.
2025-04-18Rollup merge of #139942 - dalvescb:master, r=jieyouxuMatthias Krüger-0/+1
Ignore aix for tests/ui/erros/pic-linker.rs This test case fails on AIX because of how the linker arguments are passed. Furthermore on AIX `-z text` only works in dynamic mode, making this test case irrelevant.
2025-04-18Rollup merge of #139913 - fmease:rustdoc-fix-fn-param-handling, r=GuillaumeGomezMatthias Krüger-8/+57
rustdoc/clean: Fix lowering of fn params (fixes correctness & HIR vs. middle parity regressions) **(0)** PR #136411 aimed to stop rendering unnamed params of fn ptr types as underscores in the common case (e.g., `fn(_: i32)` → `fn(i32)`) to make the rendered output stylistically more conventional. **(0.a)** However, since the cleaning fn that the PR modified is also used for lowering the HIR params of foreign fns and required assoc fns in traits, it accidentally butchered the rendering of the latter two: ```rs pub trait Trait { fn assoc_fn(_: i32); } // as well as (Rust 2015 only): fn assoc_fn(i32); unsafe extern "C" { pub fn foreign_fn(_: i32); } // Since 1.86 the fns above gets mis-rendered as: pub fn assoc_fn(: i32) // <-- BUTCHERED pub unsafe extern "C" fn foreign_fn(: i32) // <-- BUTCHERED ``` **(0.b)** Furthermore, it broke parity with middle cleaning (which includes inlined cross-crate re-exports) re-regressing parts of #44306 I once fixed in PR #103885. **(1)** Lastly, PR #139035 introduced an ICE triggered by the following input file: ```rs trait Trait { fn anon(()) {} } // internal error: entered unreachable code ``` --- This PR fixes all of these regressions and in the first commit renames several types and fns to be more ~~correct~~ descriptive and legible. ~~It also refactors `Param.name` to be of type `Option<Symbol>` instead `Symbol` (where `None` ~ `kw::Empty`), so rendering mistakes like that can no longer creep in like that (ignoring tests). CC #137978.~~ Independently done in PR #139846 a day prior.
2025-04-18Rollup merge of #139615 - nnethercote:rm-name_or_empty, r=jdonszelmannMatthias Krüger-9/+74
Remove `name_or_empty` Another step towards #137978. r? ``@jdonszelmann``
2025-04-18Rollup merge of #139393 - ↵Matthias Krüger-0/+132
willglynn:rustdoc_output_target_feature_information, r=aDotInTheVoid rustdoc-json: Output target feature information `#[target_feature]` attributes refer to a target-specific list of features. Enabling certain features can imply enabling other features. Certain features are always enabled on certain targets, since they are required by the target's ABI. Features can also be enabled indirectly based on other compiler flags. Feature information is ultimately known to `rustc`. Rather than force external tools to track it – which may be wildly impractical due to `-C target-cpu` – have `rustdoc` output `rustc`'s feature data. This change is motivated by https://github.com/obi1kenobi/cargo-semver-checks/issues/1246, which intends to detect semver hazards caused by `#[target_feature]`. try-job: aarch64-gnu try-job: armhf-gnu try-job: test-various try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: aarch64-apple
2025-04-18Rollup merge of #138528 - dianne:implicit-deref-patterns, r=NadrierilMatthias Krüger-6/+437
deref patterns: implement implicit deref patterns This implements implicit deref patterns (per https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Implicit-deref-patterns) and adds tests and an unstable book chapter. Best reviewed commit-by-commit. Overall there's a lot of additions, but a lot of that is tests, documentation, and simple(?) refactoring. Tracking issue: #87121 r? ``@Nadrieril``
2025-04-18Don't assemble non-env/bound candidates if projection is rigidMichael Goulet-17/+49
2025-04-17Rollup merge of #139971 - LukasWoodtli:gardena/lw/fix-cstring-merging-test, ↵Matthias Krüger-3/+5
r=wesleywiser Make C string merging test work on MIPS Assembly for MIPS uses, by convention, a different prefix for local anonymous variables.
2025-04-17Rollup merge of #139967 - jieyouxu:auxiliary, r=wesleywiserMatthias Krüger-60/+40
Introduce and use specialized `//@ ignore-auxiliary` for test support files instead of using `//@ ignore-test` ### Summary Add a semantically meaningful directive for ignoring test *auxiliary* files. This is for auxiliary files that *participate* in actual tests but should not be built by `compiletest` (i.e. these files are involved through `mod xxx;` or `include!()` or `#[path = "xxx"]`, etc.). ### Motivation A specialized directive like `//@ ignore-auxiliary` makes it way easier to audit disabled tests via `//@ ignore-test`. - These support files cannot use the canonical `auxiliary/` dir because they participate in module resolution or are included, or their relative paths can be important for test intention otherwise. Follow-up to: - #139705 - #139783 - #139740 See also discussions in: - [#t-compiler > Directive name for non-test aux files?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Directive.20name.20for.20non-test.20aux.20files.3F/with/512773817) - [#t-compiler > Handling disabled &#96;//@ ignore-test&#96; tests](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Handling.20disabled.20.60.2F.2F.40.20ignore-test.60.20tests/with/512005974) - [#t-compiler/meetings > &#91;steering&#93; 2025-04-11 Dealing with disabled tests](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bsteering.5D.202025-04-11.20Dealing.20with.20disabled.20tests/with/511717981) ### Remarks on remaining unconditionally disabled tests under `tests/` After this PR, against commit 79a272c6402, only **14** remaining test files are disabled through `//@ ignore-test`: <details> <summary>Remaining `//@ ignore-test` files under `tests/`</summary> ``` tests/debuginfo/drop-locations.rs 4://@ ignore-test (broken, see #128971) tests/rustdoc/macro-document-private-duplicate.rs 1://@ ignore-test (fails spuriously, see issue #89228) tests/rustdoc/inline_cross/assoc-const-equality.rs 3://@ ignore-test (FIXME: #125092) tests/ui/match/issue-27021.rs 7://@ ignore-test (#54987) tests/ui/match/issue-26996.rs 7://@ ignore-test (#54987) tests/ui/issues/issue-49298.rs 9://@ ignore-test (#54987) tests/ui/issues/issue-59756.rs 2://@ ignore-test (rustfix needs multiple suggestions) tests/ui/precondition-checks/write.rs 5://@ ignore-test (unimplemented) tests/ui/precondition-checks/read.rs 5://@ ignore-test (unimplemented) tests/ui/precondition-checks/write_bytes.rs 5://@ ignore-test (unimplemented) tests/ui/explicit-tail-calls/drop-order.rs 2://@ ignore-test: tail calls are not implemented in rustc_codegen_ssa yet, so this causes 🧊 tests/ui/panics/panic-short-backtrace-windows-x86_64.rs 3://@ ignore-test (#92000) tests/ui/json/json-bom-plus-crlf-multifile-aux.rs 3://@ ignore-test Not a test. Used by other tests tests/ui/traits/next-solver/object-soundness-requires-generalization.rs 2://@ ignore-test (see #114196) ``` </details> Of these, most are either **unimplemented**, or **spurious**, or **known-broken**. The outstanding one is `tests/ui/json/json-bom-plus-crlf-multifile-aux.rs` which I did not want to touch in *this* PR -- that aux file has load-bearing BOM and carriage returns and byte offset matters. I think those test files that require special encoding / BOM probably are better off as `run-make` tests. See #139968 for that aux file. ### Review advice - Best reviewed commit-by-commit. - The directive name diverged from the most voted `//@ auxiliary` because I think that's easy to confuse with `//@ aux-{crate,dir}`. r? compiler
2025-04-17Rollup merge of #139498 - alexcrichton:wasm-zst-safe, r=wesleywiserMatthias Krüger-0/+6
Ignore zero-sized types in wasm future-compat warning This commit fixes a false positive of the warning triggered for #138762 and the fix is to codify that zero-sized types are "safe" in both the old and new ABIs.
2025-04-17Rollup merge of #139351 - EnzymeAD:autodiff-batching2, r=oli-obkMatthias Krüger-0/+113
Autodiff batching2 ~I will rebase it once my first PR landed.~ done. This autodiff batch mode is more similar to scalar autodiff, since it still only takes one shadow argument. However, that argument is supposed to be `width` times larger. r? `@oli-obk` Tracking: - https://github.com/rust-lang/rust/issues/124509
2025-04-17tests: adjust 101082 test for LLVM 21 fixAugie Fackler-10/+2
Fixes #139987.
2025-04-17Rollup merge of #139943 - fmease:rustdoc-ixcre-trait-aliases, r=GuillaumeGomezMatthias Krüger-39/+95
rustdoc: Support inlined cross-crate re-exported trait aliases Previously we'd just drop them. As a result of this PR, [`core::ptr::Thin`](https://doc.rust-lang.org/nightly/core/ptr/traitalias.Thin.html) will be admitted into the `std` façade! Also, render the where clause *after* the bounds / the `=`, not before them, as it should be. r? rustdoc
2025-04-17Rollup merge of #139902 - lcnr:no-opaque-cast-projection, r=oli-obkMatthias Krüger-1/+4
do not emit `OpaqueCast` projections with `-Znext-solver` We normalize opaque types in their defining scope if the new solver is enabled. This means projections do not contain any 'revealable' opaque types we need to worry about. We either have a type which has been normalized by writeback or we need to normalize it anyways. r? ```@compiler-errors``` ```@oli-obk```
2025-04-17Rollup merge of #139850 - xizheyin:issue-138698, r=jieyouxuMatthias Krüger-0/+50
Hide unstable print kinds within emit_unknown_print_request_help in stable channel Fixes #138698 We need to get the channel from `matches`. However, since `matches`(Line 1169) is constructed after `rustc_optgroups` (Line1165, where `RustcOptGroup::value_hint` is generated, i.e. what `rustc --print print` prints), I've left it unchanged here for now. https://github.com/rust-lang/rust/blob/2da29dbe8fe23df1c7c4ab1d8740ca3c32b15526/compiler/rustc_driver_impl/src/lib.rs#L1161-L1169 There is actually a way to manually parse the `--crate-name` parameter, but I'm afraid that's an unorthodox practice. So I conservatively just modified `emit_unknown_print_request_help` to print different parameters depending on whether they are nightly or not when passing the error parameter. r? ```@jieyouxu```
2025-04-17Rollup merge of #139774 - compiler-errors:supertrait-alias, r=lcnrMatthias Krüger-0/+103
Fix replacing supertrait aliases in `ReplaceProjectionWith` The new solver has a procedure called `predicates_for_object_candidate`, which elaborates the super-bounds and item-bounds that are required to hold for a dyn trait to implement something via a built-in object impl. In that procedure, there is a folder called `ReplaceProjectionWith` which is responsible for replacing projections that reference `Self`, so that we don't encounter cycles when we then go on to normalize those projections in the process of proving these super-bounds. That folder had a few problems: Firstly, it wasn't actually checking that this was a super bound originating from `Self`. Secondly, it only accounted for a *single* projection type def id, but trait objects can have multiple (i.e. `trait Foo<A, B>: Bar<A, Assoc = A> + Bar<B, Assoc = B>`). To fix the first, it's simple enough to just add an equality check for the self ty. To fix the second, I implemented a matching step that's very similar to the `projection_may_match` check we have for upcasting, since on top of having multiple choices, we need to deal with both non-structural matches and ambiguity. This probably lacks a bit of documentation, but I think it works pretty well. Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/171 r? lcnr
2025-04-17run-make: drop `os_pipe` workaround now that `anonymous_pipe` is stable on betaJieyou Xu-4/+2
2025-04-17Ignore zero-sized types in wasm future-compat warningAlex Crichton-0/+6
This commit fixes a false positive of the warning triggered for #138762 and the fix is to codify that zero-sized types are "safe" in both the old and new ABIs.
2025-04-17Make C string merging test work on MIPSLukas Woodtli-3/+5
Assembly for MIPS uses, by convention, a different prefix for local anonymous variables.
2025-04-17Hide unstable print kinds within emit_unknown_print_request_help in stable ↵xizheyin-0/+50
channel Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>