Fix riscv64 fuchsia LLVM target name
Currently, riscv64gc-unknown-fuchsia (added in #108722) sets riscv64*gc*-unknown-fuchsia as the LLVM target.
1716932743/compiler/rustc_target/src/spec/riscv64gc_unknown_fuchsia.rs (L5)
However, riscv64*gc*-\* is not a valid LLVM target and causes the following error.
```console
$ rustc --print cfg --target riscv64gc-unknown-fuchsia
error: could not create LLVM TargetMachine for triple: riscv64gc-unknown-fuchsia: No available targets are compatible with triple "riscv64gc-unknown-fuchsia"
```
As with other RISC-V targets, the LLVM target should use riscv64-\*, not riscv64*gc*-\*.
1716932743/compiler/rustc_target/src/spec/riscv64gc_unknown_freebsd.rs (L5)1716932743/compiler/rustc_target/src/spec/riscv64gc_unknown_linux_gnu.rs (L5)
I confirmed that riscv64-unknown-fuchsia is recognized as a valid LLVM target by using custom targets.
```console
# create a custom target with `"llvm-target": "riscv64-unknown-fuchsia" from no-std riscv64gc target.
$ rustc --print target-spec-json -Z unstable-options --target riscv64gc-unknown-none-elf | grep -v is-builtin | sed 's/"llvm-target".*/"llvm-target": "riscv64-unknown-fuchsia",/' > riscv64gc-unknown-fuchsia.json
$ rustc --print cfg --target riscv64gc-unknown-fuchsia.json
debug_assertions
panic="abort"
target_abi=""
target_arch="riscv64"
target_endian="little"
target_env=""
target_feature="a"
target_feature="c"
target_feature="d"
target_feature="f"
target_feature="m"
...
$ cat riscv64gc-unknown-fuchsia.json
{
"arch": "riscv64",
"code-model": "medium",
"cpu": "generic-rv64",
"data-layout": "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128",
"eh-frame-header": false,
"emit-debug-gdb-scripts": false,
"features": "+m,+a,+f,+d,+c",
"linker": "rust-lld",
"linker-flavor": "ld.lld",
"llvm-abiname": "lp64d",
"llvm-target": "riscv64-unknown-fuchsia",
"max-atomic-width": 64,
"panic-strategy": "abort",
"relocation-model": "static",
"supported-sanitizers": [
"kernel-address"
],
"target-pointer-width": "64"
}
# Check the current master's LLVM target name causes an error
$ sed -i 's/riscv64-unknown-fuchsia/riscv64gc-unknown-fuchsia/' riscv64gc-unknown-fuchsia.json
$ rustc --print cfg --target riscv64gc-unknown-fuchsia.json
error: could not create LLVM TargetMachine for triple: riscv64gc-unknown-fuchsia: No available targets are compatible with triple "riscv64gc-unknown-fuchsia"
```
r? ````@tmandry````
Remove box expressions from HIR
After #108516, `#[rustc_box]` is used at HIR->THIR lowering and this is no longer emitted, so it can be removed.
This is based on top of #108471 to help with conflicts, so 43490488ccacd1a822e9c621f5ed6fca99959a0b is the only relevant commit (sorry for all the duplicated pings!)
````@rustbot```` label +S-blocked
Wrap the whole LocalInfo in ClearCrossCrate.
MIR contains a lot of information about locals. The primary purpose of this information is the quality of borrowck diagnostics.
This PR aims to drop this information after MIR analyses are finished, ie. starting from post-cleanup runtime MIR.
In cases where it is legal, we should prefer poison values over
undef values.
This replaces undef with poison for aggregate construction and
for uninhabited types. There are more places where we can likely
use poison, but I wanted to stay conservative to start with.
In particular the aggregate case is important for newer LLVM
versions, which are not able to handle an undef base value during
early optimization due to poison-propagation concerns.
Flatten/inline format_args!() and (string and int) literal arguments into format_args!()
Implements https://github.com/rust-lang/rust/issues/78356
Gated behind `-Zflatten-format-args=yes`.
Part of #99012
This change inlines string literals, integer literals and nested format_args!() into format_args!() during ast lowering, making all of the following pairs result in equivalent hir:
```rust
println!("Hello, {}!", "World");
println!("Hello, World!");
```
```rust
println!("[info] {}", format_args!("error"));
println!("[info] error");
```
```rust
println!("[{}] {}", status, format_args!("error: {}", msg));
println!("[{}] error: {}", status, msg);
```
```rust
println!("{} + {} = {}", 1, 2, 1 + 2);
println!("1 + 2 = {}", 1 + 2);
```
And so on.
This is useful for macros. E.g. a `log::info!()` macro could just pass the tokens from the user directly into a `format_args!()` that gets efficiently flattened/inlined into a `format_args!("info: {}")`.
It also means that `dbg!(x)` will have its file, line, and expression name inlined:
```rust
eprintln!("[{}:{}] {} = {:#?}", file!(), line!(), stringify!(x), x); // before
eprintln!("[example.rs:1] x = {:#?}", x); // after
```
Which can be nice in some cases, but also means a lot more unique static strings than before if dbg!() is used a lot.
Some cleanups in our normalization logic
Changed a match to be exhaustive and deduplicated some code.
r? ```@compiler-errors```
this pulls out the uncontroversial part of https://github.com/rust-lang/rust/pull/108860
make `define_opaque_types` fully explicit
based on the idea of #108389. Moved `define_opaque_types` into the actual operations, e.g. `eq`, instead of `infcx.at` because normalization doesn't use `define_opaque_types` and even creates it's own `At` with a different `define_opaque_types` internally.
Somewhat surprisingly, coherence actually relies on `DefineOpaqueTypes::Yes` for soundness which was revealed because I've incorrectly used `DefineOpaqueTypes::No` in `equate_impl_headers`. It feels concerning that even though this is the case, we still sometimes use `DefineOpaqueTypes::No` in coherence. I did not look into this as part of this PR as it is purely changing the structure of the code without changing behavior in any way.
r? ```@oli-obk```
error-msg: impl better suggestion for `E0532`
Fixes#106862
No test as there is already a test which is nearly identical to the example in the linked issue.
Revert #107376 to fix potential `bincode` breakage and `rustc-perf` benchmark.
#107376 caused `rustc-perf`'s `webrender` benchmark to break, by regressing on the `bincode-1.3.3` crate.
~~This PR is a draft revert in case we can't land a fix soon enough, and we'd like to land the revert instead~~
(Though I myself think it'd be safer to do the revert, and run crater when relanding #107376.)
cc `@aliemjay`
Implement checked Shl/Shr at MIR building.
This does not require any special handling by codegen backends,
as the overflow behaviour is entirely determined by the rhs (shift amount).
This allows MIR ConstProp to remove the overflow check for constant shifts.
~There is an existing different behaviour between cg_llvm and cg_clif (cc `@bjorn3).`
I took cg_llvm's one as reference: overflow if `rhs < 0 || rhs > number_of_bits_in_lhs_ty`.~
EDIT: `cg_llvm` and `cg_clif` implement the overflow check differently. This PR uses `cg_llvm`'s implementation based on a `BitAnd` instead of `cg_clif`'s one based on an unsigned comparison.
Sync rustc_codegen_cranelift
Bunch of bug fixes this time. Also an update to Cranelift 0.93 which adds a brand new optimization pass which cg_clif exposes when using `--release`. And various improvements to cg_clif's test suite, making it faster to run. And finally two small perf improvements.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
