| Age | Commit message (Collapse) | Author | Lines |
|---|
|
rustfmt fails to format this match expression, because it has several
long string literals over the maximum line width. This seems to exhibit
rustfmt issues #3863 (Gives up on chains if any line is too long) and
#3156 (Fail to format match arm when other arm has long line).
|
|
r=Mark-Simulacrum,jieyouxu
Always set the deployment target when building std
`cc` has [a bug/feature](https://github.com/rust-lang/cc-rs/issues/1171) (I guess depending on how you look at it) where the default deployment target is taken from the SDK instead of from `rustc`. This causes `compiler-builtins` to build `compiler-rt` with the wrong deployment target on iOS.
I've been meaning to change how `cc` works in this regard, but that's a lengthy process, so let's fix it in bootstrap for now.
The behaviour can be seen locally with `./x build library --set build.optimized-compiler-builtins=true` for various target triples, and then inspecting with `otool -l build/host/stage1/lib/rustlib/*/lib/libcompiler_builtins-*.rlib | rg 'minos|version'`. I have added a rmake test that ensures that we now have the same version everywhere.
Fixes https://github.com/rust-lang/rust/issues/128419
Fixes https://github.com/rust-lang/compiler-builtins/issues/650
Fixes https://github.com/rust-lang/rust/issues/136523
See also https://github.com/rust-lang/cargo/issues/13115, https://github.com/rust-lang/cc-rs/issues/1171, https://github.com/rust-lang/rust/issues/136113
See https://github.com/rust-lang/rust/pull/133092#issuecomment-2626206772 for a description of how the change works.
try-job: i686-gnu-1
try-job: i686-gnu-2
try-job: x86_64-apple-1
try-job: aarch64-apple
try-job: dist-apple-various
try-job: dist-aarch64-apple
try-job: dist-various-2
try-job: x86_64-fuchsia
|
|
Rollup of 6 pull requests
Successful merges:
- #136419 (adding autodiff tests)
- #136628 (ci: upgrade to crosstool-ng 1.27.0)
- #136681 (resolve `llvm-config` path properly on cross builds)
- #136714 (Update `compiler-builtins` to 0.1.146)
- #136731 (rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync")
- #136791 (Disable DWARF in linker options for i686-unknown-uefi)
Failed merges:
- #136767 (improve host/cross target checking)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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::back::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?)
|
|
Update `compiler-builtins` to 0.1.146
Exposes the error function so we can expose this in the standard library [1].
[1]: https://github.com/rust-lang/compiler-builtins/pull/753
|
|
resolve `llvm-config` path properly on cross builds
Fixes #132926
try-job: x86_64-mingw-2
|
|
ci: upgrade to crosstool-ng 1.27.0
try-job: dist-loongarch64-linux
try-job: dist-loongarch64-musl
try-job: dist-powerpc64le-linux
|
|
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
|
|
r=workingjubilee
Portable SIMD subtree update
r? `@workingjubilee`
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Rollup of 12 pull requests
Successful merges:
- #136053 (coverage: Defer part of counter-creation until codegen)
- #136201 (Removed dependency on the field-offset crate, alternate approach)
- #136228 (Simplify Rc::as_ptr docs + typo fix)
- #136353 (fix(libtest): Enable Instant on Emscripten targets)
- #136472 ([`compiletest`-related cleanups 2/7] Feed stage number to compiletest directly)
- #136487 (ci: stop mysql before removing it)
- #136552 (Use an `Option` for `FindNextFileHandle` in `ReadDir` instead of `INVALID_FILE_HANDLE` sentinel value)
- #136705 (Some miscellaneous edition-related library tweaks)
- #136707 (Bump `cc` to v1.2.13 for the compiler workspace)
- #136790 (Git blame ignore recent formatting commit)
- #136792 (Don't apply editorconfig to llvm)
- #136805 (ignore win_delete_self test in Miri)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
ignore win_delete_self test in Miri
Follow-up to https://github.com/rust-lang/rust/pull/134679, fixes miri-test-libstd on Windows
Cc `@ChrisDenton` `@Mark-Simulacrum`
|
|
Don't apply editorconfig to llvm
They use 2 spaces by default, not 4.
|
|
Git blame ignore recent formatting commit
This ignores the commit 1fcae03369abb4c2cc180cd5a49e1f4440a81300 from https://github.com/rust-lang/rust/pull/136751 that applied updating formatting changes.
|
|
Bump `cc` to v1.2.13 for the compiler workspace
|
|
Some miscellaneous edition-related library tweaks
Some library edition tweaks that can be done separately from upgrading the whole standard library to edition 2024 (which is blocked on getting the submodules upgraded, for example)
|
|
Use an `Option` for `FindNextFileHandle` in `ReadDir` instead of `INVALID_FILE_HANDLE` sentinel value
Sometimes we store an invalid handle when we don't want to return an error. We then check the handle before use in order to avoid actually using the invalid handle. However, using an `Option` for this is better and avoids us forgetting to check the handle is valid. This was noticed due to us closing the handle without checking for validity: https://github.com/rust-lang/rust/blob/bd6a6777f5cbbec549f123995026cef76d1e6b84/library/std/src/sys/pal/windows/fs.rs#L148-L151
|
|
ci: stop mysql before removing it
try-job: aarch64-gnu
|
|
[`compiletest`-related cleanups 2/7] Feed stage number to compiletest directly
Reference for overall changes: https://github.com/rust-lang/rust/pull/136437
Part **2** of **7** of the *`compiletest`-related cleanups* PR series.
### Summary
- Pass stage number via new `--stage` compiletest flag directly from bootstrap, instead of deriving that info in compiletest by doing gymnastics on `--stage-id`.
- Just a cleanup, should have no functional changes.
r? bootstrap
|
|
fix(libtest): Enable Instant on Emscripten targets
`Instant::now()` works correctly on Emscripten since https://github.com/rust-lang/libc/pull/3962. All wasm-family targets with OS support can now handle instants.
Improves #131738.
~~This changes the behavior of libtest on `unknown-unknown`/`unknown-none` wasm targets, but as far as I can see, libtest doesn't support them anyway. (Can anyone double-check?)~~ UPD: this patch no longer affects `unknown-unknown` targets.
``@rustbot`` label +A-libtest +T-testing-devex +O-emscripten +O-wasm -needs-triage
|
|
Simplify Rc::as_ptr docs + typo fix
|
|
r=Mark-Simulacrum
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.)
|
|
Subtree update of `rust-analyzer`
r? `@ghost`
|
|
|
|
|
|
|
|
|
|
minor: Sync from downstream
|
|
|
|
|
|
|
|
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).
|
|
Rollup of 7 pull requests
Successful merges:
- #135488 (Stabilize `vec_pop_if`)
- #136068 (crashes: more tests)
- #136694 (Update minifier version to `0.3.4`)
- #136722 (Visit all debug info in MIR Visitor)
- #136746 (Emit an error if `-Zdwarf-version=1` is requested)
- #136760 (Fix unwrap error in overflowing int literal)
- #136782 (Fix mistake in x86_64-unknown-freebsd platform description)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
They use 2 spaces by default, not 4.
|
|
`Instant::now()` works correctly on Emscripten since
https://github.com/rust-lang/libc/pull/3962. All wasm-family targets
with OS support can now handle instants.
|
|
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::back::link=info
cargo +stage1 build --release --target i686-unknown-uefi
|
|
|
|
Fix mistake in x86_64-unknown-freebsd platform description
Fixes the description for x86_64-unknown-freebsd which looks to inadvertently say amd64.
|
|
Fix unwrap error in overflowing int literal
Fixes #136675
it's maybe `negative` only from [check_lit](https://github.com/chenyukang/rust/blob/526e3288feb68eac55013746e03fb54d6a0b9a1e/compiler/rustc_lint/src/types.rs#L546), in this scenario the fields in `TypeLimits` is none.
r? ``@oli-obk``
|
|
Emit an error if `-Zdwarf-version=1` is requested
DWARF 1 is very different than DWARF 2+[^1] and LLVM does not really seem to support DWARF 1 as Clang does not offer a `-gdwarf-1` flag[^2] and `llc` will just generate DWARF 2 with the version set to 1[^3].
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.
cc #103057
[^1]: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-gdwarf
[^2]: https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-gdwarf
[^3]: https://godbolt.org/z/s85d87n3a
|
|
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.
|
|
Update minifier version to `0.3.4`
It fixes a bug where a whitespace would get removed in `a [attribute]` (you're not forced to add a tag before an attribute selector).
r? ````@notriddle````
|
|
crashes: more tests
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
|
|
Stabilize `vec_pop_if`
Tracking issue: #122741
FCP completed in https://github.com/rust-lang/rust/issues/122741#issuecomment-2605116387
|
|
|
|
|
|
|
