compiletest: Remove the "wasm32-bare" alias for `wasm32-unknown-unknown`
- Follow-up to https://github.com/rust-lang/rust/pull/148969
This "wasm32-bare" alias, understood by compiletest's `//@ ignore-wasm32-bare` and `//@ only-wasm32-bare` directives, dates all the way back to the original introduction of the `wasm32-unknown-unknown` target in https://github.com/rust-lang/rust/pull/45905.
But there is no compelling reason to use an alias instead of the full target name.
r? jieyouxu
Abi compatibility test cleanup
r? `@jieyouxu`
- moves `NonNull` (and some friends) into `minicore.rs` so it can be re-used.
- tests the abi compatibility of a couple more targets. It's useful to have a comprehensive overview of all ABIs that rust has some amount of support for, e.g. testing for c-variadic or guaranteed tail calls (cc https://github.com/rust-lang/rust/issues/148748)
Error if an autodiff user does not set lto=fat
Based on your feedback, I started to provide a nice error message for a lack of `lto=fat`, instead of us forcing it.
In a next step, we should replace `RUSTFLAGS="-Zautodiff=Enable"` with another Cargo.toml setting, as discussed here: https://github.com/rust-lang/rust/issues/147487#issuecomment-3446558644
As another improvement, we should also figure out why rlib builds do not properly obey the fat=lto setting.
```````@bjorn3```````
add larger test for `proc_macro` `FromStr` implementations
Currently, there are only few tests that check the output of `TokenStream::from_str` and `Literal::from_str` (which is somewhat understandable as the rustc implementation just delegates these calls to the parser). In preparation for both the standalone backend (rust-lang/rust#130856) which will probably need to reimplement this logic as well as for removing panics from these functions (rust-lang/rust#58736), this PR adds a test which shows the various messy ways of how these functions report errors and the return values for successful parses.
Followup PRs such as rust-lang/rust#147859 will change more and more of these "diagnostic + error"s into `LexErrors`.
The test structure with the extra module is used to allow reusing it later easily for the standalone backend.
use funnel shift as fallback impl for rotating shifts
That lets us remove this gnarly implementation from Miri and const-eval.
However, `rotate_left`/`rotate_right` are stable as const fn, so to do this we have to `rustc_allow_const_fn_unstable` a bunch of const trait stuff. Is that a bad idea? Cc `@oli-obk` `@fee1-dead`
Add another *ExprWithBlock* test for `try` blocks
Looking to address this open item from rust-lang/rust#31436
> Add a test confirming that it's an `ExprWithBlock`, so works in a match arm without a comma
It turns out that rust-lang/rust#120540 addressed that one, but it made me think of this other case that probably ought to have some kind of test as well.
re-enable wasm abi test
The `wasm32-unknown-unknown` ABI has been fixed for a while now https://github.com/rust-lang/rust/issues/115666, so this test can be re-enabled and the fixme removed.
r? ``@bjorn3``
Fix overflow-checks test for RISC-V target
The overflow-checks codegen test was failing on riscv64gc target because the FileCheck pattern did not account for ABI extension attributes. RISC-V LP64 ABI requires integer types smaller than XLEN (64-bit) to be zero-extended or sign-extended to register width.
For u8 parameters, RISC-V generates:
i8 noundef zeroext %a, i8 noundef zeroext %b
While x86_64 and aarch64 generate:
i8 noundef %a, i8 noundef %b
The original CHECK pattern only matched the format without the `zeroext` attribute, causing test failures on RISC-V.
This patch makes the zeroext attribute optional in the FileCheck pattern using `{{( zeroext)?}}`, allowing the test to pass on architectures that add ABI extension attributes (e.g., RISC-V).
Test results before fix:
- x86_64-unknown-linux-gnu: 3 passed
- aarch64-unknown-linux-gnu: 3 passed
- riscv64gc-unknown-linux-gnu: 1 passed, 2 failed
Test results after fix:
- x86_64-unknown-linux-gnu: 3 passed
- aarch64-unknown-linux-gnu: 3 passed
- riscv64gc-unknown-linux-gnu: 3 passed
compute temporary scopes when building MIR, not THIR
This accomplishes two things:
- Makes the THIR slightly smaller by not attaching a full `TempLifetime` to every expression.
- Reduces the number of traversals of the `ScopeTree` by only calling `ScopeTree::temporary_scope` when building MIR for something that needs to be dropped in a temporary scope.
add assembly test for infinite recursion with `become`
tracking issue: https://github.com/rust-lang/rust/issues/112788
fixes https://github.com/rust-lang/rust/issues/125698
Check that infinite recursion via `become` does not grow the stack (even on opt-level 0). The incomplete implementation of `become` did not guarantee that earlier. Although it's unlikely this ever regresses we may as well test it and close the issue.
r? ```@WaffleLapkin```
Disable rustdoc-test-builder test partially for SGX target.
The `rustdoc-test-builder` test started to fail after https://github.com/rust-lang/rust/pull/148608 for SGX target. The reason is, sgx binary can not be executed directly so rustdoc fails to execute passed `--test-builder` binary. This PR simply ignores the success part just like it is ignore for `wasm` target.
error when ABI does not support guaranteed tail calls
Some ABIs cannot support guaranteed tail calls. There isn't really an exhaustive list, so this is a best effort. Conveniently, we already disallow calling most of these directly anyway. The only exception that I was able to trigger an LLVM assertion with so far was `cmse-nonsecure-entry`.
For that calling convention, LLVM specifically notes that (guaranteed) tail calls cannot be supported:
https://github.com/llvm/llvm-project/blob/28dbbba6c3a4e026e085c48cc022cb97b5d8bc6d/llvm/lib/Target/ARM/ARMISelLowering.cpp#L2331-L2335
---
I have some doubts about the implementation here though. I think it would be nicer to use `CanonAbi`, and move the `become` ABI check into `rustc_hir_typeck`, similar to `check_call_abi`:
https://github.com/rust-lang/rust/blob/d6deffe2debecc66501e50f9573214139ab4d678/compiler/rustc_hir_typeck/src/callee.rs#L157-L194
Both the check for whether an ABI is callable and whether it supports guaranteed tail calls can then be methods (containing exhaustive matches) on `CanonAbi`. I'm however not sure
- if the ABI checks are deliberately only performed when constructing MIR
- what assumptions can be made about the `call` expression in [`check_expr_become`](https://github.com/rust-lang/rust/blob/d6deffe2debecc66501e50f9573214139ab4d678/compiler/rustc_hir_typeck/src/expr.rs#L1126-L1150), it looks like currently the check that the "argument" to `become` is a function call also only occurs later during MIR construction
Are there issues with validating the ABI earlier in `rustc_hir_typeck` that I'm overlooking? I believe that we should already know the call's ABI and whether it is c-variadic at that point.
cc ````@workingjubilee```` for `CanonAbi`, ````@davidtwco```` for cmse
r? ````@WaffleLapkin````
Correctly link to associated trait items in reexports
Fixesrust-lang/rust#148008.
Issue was that we didn't add anchors in this case.
r? ``````@lolbinarycat``````
rustc_codegen_llvm: Require `opt-level >= 1` for index-based write_operand_repeatedly() loop
To make debugger stepping intuitive with `-Copt-level=0`. See the adjusted `basic-stepping.rs` test.
This is kind of a revert of **bd0aae92dc76d9 (cg_llvm: use index-based loop in write_operand_repeatedly)**, except we don't revert it, we just make it conditional on `opt-level`. That commit regressed `basic-stepping.rs`, but it was not noticed since that test did not exist back then (it was added later in rust-lang/rust#144876). I have retroactively bisected to find that out.
It seems messy to sprinkle if-cases inside of
`write_operand_repeatedly()` so make the whole function conditional.
The test that bd0aae92dc added in
`tests/codegen/issues/issue-111603.rs` already use `-Copt-level=3`, so we don't need to adjust the compiler flags for it to keep passing.
This PR takes us one step closer to fixing rust-lang/rust#33013.
CC rust-lang/rust#147426 which is related (there will be trivial conflicts for me to resolve in basic-stepping.rs once one of them lands)
bors