Show diff suggestion format on verbose replacement
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL - let _ = 2.l;
LL + let _ = 2.0f64;
|
```
before:
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL + let _ = 2.0f64;
| ~~~~
```
r? `@oli-obk`
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL - let _ = 2.l;
LL + let _ = 2.0f64;
|
```
Disable DWARF in linker options for i686-unknown-uefi
This fixes an lld warning:
> warning: linker stderr: rust-lld: section name .debug_frame is longer than 8 characters and will use a non-standard string table
See https://reviews.llvm.org/D69594 for details of where the warning was added.
This warning only occurs with the i686 UEFI target, not x86_64 or aarch64. The x86_64 target uses an LLVM target of
`x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in `i686_unknown_uefi.rs` for details of why.
The `.debug_frame` section should not actually be needed; UEFI targets provide a separate PDB file for debugging. Disable DWARF (and by extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld.
Tested with:
```
export RUSTC_LOG=rustc_codegen_ssa:🔙:link=info
cargo +stage1 build --release --target i686-unknown-uefi
```
This issue was originally raised here: https://github.com/rust-lang/rust/pull/119286#issuecomment-2612746162. See also https://github.com/rust-lang/rust/issues/136096. It was suggested to file an LLVM bug, but I don't think LLVM is actually doing anything wrong as such.
CC `@dvdhrm` `@jyn514` let me know if you have any feedback on this approach
rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync"
rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync"
We don't need to "short circuit trait resolution", because DynSend and DynSync are auto traits and thus coinductive
cc "Parallel Rustc Front-end" https://github.com/rust-lang/rust/issues/113349
r? SparrowLii
``@rustbot`` label: +WG-compiler-parallel
(rustbot sometimes ignores me and doesn't attach labels on my behalf. rustbot banned me?)
adding autodiff tests
I'd like to get started with upstreaming some tests, even though I'm still waiting for an answer on how to best integrate the enzyme pass. Can we therefore temporarily support the -Z llvm-plugins here without too much effort? And in that case, how would that work? I saw you can do remapping, e.g. `rust-src-base`, but I don't think that will give me the path to libEnzyme.so. Do you have another suggestion?
Other than that this test simply checks that the derivative of `x*x` is `2.0 * x`, which in this case is computed as
`%0 = fadd fast double %x.0.val, %x.0.val`
(I'll add a few more tests and move it to an autodiff folder if we can use the -Z flag)
r? ``@jieyouxu``
Locally at least `-Zllvm-plugins=${PWD}/build/x86_64-unknown-linux-gnu/enzyme/build/Enzyme/libEnzyme-19.so` seems to work if I copy the command I get from x.py test and run it manually. However, running x.py test itself fails.
Tracking:
- https://github.com/rust-lang/rust/issues/124509
Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Enzyme.20build.20changes
Removed dependency on the field-offset crate, alternate approach
This is an alternate approach to reach the same goals as #136003. As it touches the core of the query system, this too probably should be evaluated for performance.
r? ``@Mark-Simulacrum``
coverage: Defer part of counter-creation until codegen
Follow-up to #135481 and #135873.
One of the pleasant properties of the new counter-assignment algorithm is that we can stop partway through the process, store the intermediate state in MIR, and then resume the rest of the algorithm during codegen. This lets it take into account which parts of the control-flow graph were eliminated by MIR opts, resulting in fewer physical counters and simpler counter expressions.
Those improvements end up completely obsoleting much larger chunks of code that were previously responsible for cleaning up the coverage metadata after MIR opts, while also doing a more thorough cleanup job.
(That change also unlocks some further simplifications that I've kept out of this PR to limit its scope.)
Add amdgpu target
Add amdgpu target to rustc and enable the LLVM target.
Fix compiling `core` with the amdgpu:
The amdgpu backend makes heavy use of different address spaces. This
leads to situations, where a pointer in one addrspace needs to be casted
to a pointer in a different addrspace. `bitcast` is invalid for this
case, `addrspacecast` needs to be used.
Fix compilation failures that created bitcasts for such cases by
creating pointer casts (which creates an `addrspacecast` under the hood)
instead.
MCP: https://github.com/rust-lang/compiler-team/issues/823
Tracking issue: #135024
Kinda related to the original amdgpu tracking issue #51575 (though that one has been closed for a while).
This fixes an lld warning:
> warning: linker stderr: rust-lld: section name .debug_frame is longer
> than 8 characters and will use a non-standard string table
See https://reviews.llvm.org/D69594 for details of where the warning was
added.
This warning only occurs with the i686 UEFI target, not x86_64 or
aarch64. The x86_64 target uses an LLVM target of
`x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but
i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in
`i686_unknown_uefi.rs` for details of why.
The `.debug_frame` section should not actually be needed; UEFI targets
provide a separate PDB file for debugging. Disable DWARF (and by
extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld.
Tested with:
export RUSTC_LOG=rustc_codegen_ssa:🔙:link=info
cargo +stage1 build --release --target i686-unknown-uefi
Visit all debug info in MIR Visitor
I've been experimenting with simplifying debug info in MIR inliner, and discovered that MIR Visitor doesn't reliably visit all spans. This PR adds the missing visitor calls.
DWARF 1 is very different than DWARF 2+ (see the commentary in
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-gdwarf)
and LLVM does not really seem to support DWARF 1 as Clang does not offer
a `-gdwarf-1` flag and `llc` will just generate DWARF 2 with the version
set to 1: https://godbolt.org/z/s85d87n3a.
Since this isn't actually supported (and it's not clear it would be
useful anyway), report that DWARF 1 is not supported if it is requested.
Also add a help message to the error saying which versions are supported.
Update bootstrap compiler and rustfmt
The rustfmt version we previously used formats things differently from what the latest nightly rustfmt does. This causes issues for subtrees that get formatted both in-tree and in their own repo. Updating the rustfmt used in-tree solves those issues. Also bumped the bootstrap compiler as the stage0 update command always updates both at the same
time.
Rollup of 5 pull requests
Successful merges:
- #134679 (Windows: remove readonly files)
- #136213 (Allow Rust to use a number of libc filesystem calls)
- #136530 (Implement `x perf` directly in bootstrap)
- #136601 (Detect (non-raw) borrows of null ZST pointers in CheckNull)
- #136659 (Pick the max DWARF version when LTO'ing modules with different versions )
r? `@ghost`
`@rustbot` modify labels: rollup
Small resolve refactor
I was looking into how resolve works in order to find a good way for clippy to shorten paths in messages and suggestions, and found a needless `.collect()` and a recursive function that could be written as a loop, also removed a panicky code path.
transmutability: fix ICE when passing wrong ADT to ASSUME
- Remove an incorrect assert that the `ASSUME` parameter has the type `Assume` and delay a bug instead.
- Since we checked the type of `ASSUME` is `Assume` (an ADT), its valtree must be a branch, so we can just unwrap it.
r? ```@jswrenn```
compiler: mostly-finish `rustc_abi` updates
This almost-finishes all the updates in the compiler to use `rustc_abi` and removes some of the reexports of `rustc_abi` items in `rustc_target` that were previously available.
r? ```@compiler-errors```
Pick the max DWARF version when LTO'ing modules with different versions
Currently, when rustc compiles code with `-Clto` enabled that was built
with different choices for `-Zdwarf-version`, a warning will be
reported. It's very easy to observe this by compiling most anything (eg,
"hello world") and specifying `-Clto -Zdwarf-version=5` since the
standard library is distributed with `-Zdwarf-version=4`.
This behavior isn't actually useful for a few reasons:
- From observation, LLVM chooses to pick the highest DWARF version
anyway after issuing the warning.
- Clang specifies that in this case, the max version should be picked
without a warning and as a general principle, we want to support
x-lang LTO with Clang which implies using the same module flag merge
behaviors.
- Debuggers need to be able to handle a variety of versions within the
same debugging session as you can easily have some parts of a binary
(or some dynamic libraries within an application) all compiled with
different DWARF versions.
This commit changes the module flag merge behavior to match Clang and
use the highest version of DWARF. It also adds a test to ensure this
behavior is respected in the case of two crates being LTO'd together and
adds a test to ensure no warning is printed.
Fixes#130041 which fails due to these warnings being printed
cc #103057
Make empty-line-after an early clippy lint
r? ```@y21```
95% a refiling of https://github.com/rust-lang/rust-clippy/pull/13658 but for correctness it needed 2 extra methods in `rust_lint` which made it much easier to apply on `rust-lang/rust` than `rust-lang/rust-clippy`.
Commits have been thoroughly reviewed on `rust-lang/clippy already`. The last two review comments there (about using `Option` and popping for assoc items have been applied here.
Generate correct terminate block under Wasm EH
This fixes failing LLVM assertions during insnsel.
Improves #135665.
r? bjorn3
^ you reviewed the PR bringing Wasm EH in, I assume this is within your area of expertise?
Subtree sync for rustc_codegen_cranelift
The main highlights this time are a Cranelift update and a fix for a warning that the x87 feature is not enabled.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler<!-- homu-ignore:start -->
Currently, when rustc compiles code with `-Clto` enabled that was built
with different choices for `-Zdwarf-version`, a warning will be
reported. It's very easy to observe this by compiling most anything (eg,
"hello world") and specifying `-Clto -Zdwarf-version=5` since the
standard library is distributed with `-Zdwarf-version=4`.
This behavior isn't actually useful for a few reasons:
- from observation, LLVM chooses to pick the highest DWARF version
anyway after issuing the warning
- Clang specifies that in this case, the max version should be picked
without a warning and as a general principle, we want to support
x-lang LTO with Clang which implies using the same module flag merge
behaviors
- Debuggers need to be able to handle a variety of versions withing the
same debugging session as you can easily have some parts of a binary
(or some dynamic libraries within an application) all compiled with
different DWARF versions
This commit changes the module flag merge behavior to match Clang and
use the highest version of DWARF. It also adds a test to ensure this
behavior is respected in the case of two crates being LTO'd together and
updates the test added in the previous commit to ensure no warning is
printed.
Rollup of 6 pull requests
Successful merges:
- #136640 (Debuginfo for function ZSTs should have alignment of 8 bits, not 1 bit)
- #136648 (Add a missing `//@ needs-symlink` to `tests/run-make/libs-through-symlinks`)
- #136651 (Label mismatched parameters at the def site for foreign functions)
- #136691 (Remove Linkage::Private and Linkage::Appending)
- #136692 (add module level doc for bootstrap:utils:exec)
- #136700 (i686-unknown-hurd-gnu: bump baseline CPU to Pentium 4)
r? `@ghost`
`@rustbot` modify labels: rollup
Label mismatched parameters at the def site for foreign functions
Nice and simple. Adds parameter marking for the only missing definition type.
r? ``@compiler-errors``
Debuginfo for function ZSTs should have alignment of 8 bits, not 1 bit
In #116096, function ZSTs were made to have debuginfo that gives them an alignment of “1”. But because alignment in LLVM debuginfo is denoted in *bits*, not bytes, this resulted in an alignment specification of 1 bit instead of 1 byte.
I don't know whether this has any practical consequences, but I noticed that a test started failing when I accidentally fixed the mistake while working on #136632, so I extracted the fix (and the test adjustment) to this PR.
Rollup of 7 pull requests
Successful merges:
- #135179 (Make sure to use `Receiver` trait when extracting object method candidate)
- #136554 (Add `opt_alias_variances` and use it in outlives code)
- #136556 ([AIX] Update tests/ui/wait-forked-but-failed-child.rs to accomodate exiting and idle processes.)
- #136589 (Enable "jump to def" feature on rustc docs)
- #136615 (sys: net: Add UEFI stubs)
- #136635 (Remove outdated `base_port` calculation in std net test)
- #136682 (Move two windows process tests to tests/ui)
r? `@ghost`
`@rustbot` modify labels: rollup
Enable "jump to def" feature on rustc docs
This PR enables the rustdoc "jump to def" feature which is visible on the source code pages.
r? ``@oli-obk``
