| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Remove the ptr_unique lang item
Miri no longer uses it since https://github.com/rust-lang/miri/pull/4307.
|
|
fix handling of base address for TypeId allocations
This fixes the problems discovered by ````@theemathas```` in https://github.com/rust-lang/rust/pull/142789:
- const-eval would sometimes consider TypeId pointers to be null
- the type ID is different in Miri than in regular executions
Both boil down to the same issue: the TypeId "allocation" has a guaranteed 0 base address, but const-eval assumes it was non-zero (like normal allocations) and Miri randomized it (like normal allocations).
r? ````@oli-obk````
|
|
Add approval blocking labels for new bors
If a PR contains these labels, new bors won't let anyone approve it. We don't merge PRs using new bors yet, ofc, but I wanted to prepare this so that I don't forget about it.
This was proposed here: [#t-lang/meetings > Triage meeting 2025-07-23 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-07-23/near/529407150) and implemented [here](https://github.com/rust-lang/bors/pull/367).
CC ````@RalfJung````
r? ````@oli-obk````
|
|
Mitigate `#[align]` name resolution ambiguity regression with a rename
Mitigates beta regression rust-lang/rust#143834 after a beta backport.
### Background on the beta regression
The name resolution regression arises due to rust-lang/rust#142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as
```rs
macro_rules! align {
() => {
/* .. */
};
}
pub(crate) use align; // `use` here becomes ambiguous
```
### Mitigation approach
This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by:
1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`.
2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`.
This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622).
### Alternative mitigation options
[Various mitigation options were considered during the compiler triage meeting](https://github.com/rust-lang/rust/issues/143834#issuecomment-3084415277), and those consideration are partly reproduced here:
- Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own.
- Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying.
- Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code.
- This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code.
- This avoids backing out a whole implementation.
### Review advice
This PR is best reviewed commit-by-commit.
- Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master.
- Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass.
This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.
|
|
clippy: make tests work in stage 1
This finally fixes https://github.com/rust-lang/rust/issues/78717 :)
Similar to what Miri already does, the clippy test step needs to carefully consider which compiler is used to build clippy and which compiler is linked into clippy (and thus must be used to build the test dependencies). On top of that we have some extra complications that Miri avoided by using `cargo-miri` for building its test dependencies: we need cargo to use the right rustc and the right sysroot, but https://github.com/rust-lang/cargo/issues/4423 makes this quite hard to do. See the long comment in `src/tools/clippy/tests/compile-test.rs` for details.
Some clippy tests tried to import rustc crates; that fundamentally requires a full bootstrap loop so it cannot work in stage 1. I had to kind of guess what those tests were doing so I don't know if my changes there make any sense.
Cc ```@flip1995``` ```@Kobzol```
|
|
rustc_public: de-StableMIR-ize
This PR updates relevant docs about StableMIR, basically just rewording StableMIR/SMIR to rustc_public/rustc_public's IR.
The README.md in the `rustc_public` crate is out-dated. I plan to rewrite it after we fork rustc_public into its own repository.
This PR doesn't change the fact that we still use `-Z unpretty=stable-mir` as a rustc parameter for printing the IR, since I feel it's a bit verbose and weird if we use `-Z unpretty=rustc-public-ir`. I was wondering if we can have a short and easy alias for rustc_public's IR.
|
|
Implement `check` for compiletest and RA using tool macro
Small cleanup to reduce the number of places that require custom check steps. Of course I had to include one mini hack because of Rust Analyzer.. but I think it's worth it here.
r? ````@jieyouxu````
|
|
Constify Try, From, TryFrom and relevant traits
|
|
Lower extra lifetimes before normal generic params.
Fixes https://github.com/rust-lang/rust/issues/143413
|
|
gpu offload host code generation
r? ghost
This will generate most of the host side code to use llvm's offload feature.
The first PR will only handle automatic mem-transfers to and from the device.
So if a user calls a kernel, we will copy inputs back and forth, but we won't do the actual kernel launch.
Before merging, we will use LLVM's Info infrastructure to verify that the memcopies match what openmp offloa generates in C++. `LIBOMPTARGET_INFO=-1 ./my_rust_binary` should print that a memcpy to and later from the device is happening.
A follow-up PR will generate the actual device-side kernel which will then do computations on the GPU.
A third PR will implement manual host2device and device2host functionality, but the goal is to minimize cases where a user has to overwrite our default handling due to performance issues.
I'm trying to get a full MVP out first, so this just recognizes GPU functions based on magic names. The final frontend will obviously move this over to use proper macros, like I'm already doing it for the autodiff work.
This work will also be compatible with std::autodiff, so one can differentiate GPU kernels.
Tracking:
- https://github.com/rust-lang/rust/issues/131513
|
|
compiler-builtins subtree update
Subtree update of `compiler-builtins` to https://github.com/rust-lang/compiler-builtins/commit/2cdde03950e8d10d37b8d13e1c1d3ce2e54f36c4.
Created using https://github.com/rust-lang/josh-sync.
Fixes: https://github.com/rust-lang/rust/issues/144076
r? `@ghost`
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#144144 (tests: Skip supported-crate-types test on musl hosts)
- rust-lang/rust#144159 (opt-dist: change build_dir field to be an actual build dir)
- rust-lang/rust#144162 (Debug impls for DropElaborators)
- rust-lang/rust#144189 (Add non-regression test for rust-lang/rust#144168)
- rust-lang/rust#144216 (Don't consider unstable fields always-inhabited)
- rust-lang/rust#144229 (Miri subtree update)
- rust-lang/rust#144230 (Option::as_slice: fix comment)
- rust-lang/rust#144235 (Fix run-make tests on musl hosts)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Fix run-make tests on musl hosts
On musl hosts, we already set `-Ctarget-feature=-crt-static` and `IS_MUSL_HOST=1` in compiletest. However, in order for the run-make tests to compile fine on musl hosts, we need to propagate this flag in our rustc invocations to ensure we can generate cdylibs.
|
|
Option::as_slice: fix comment
The implementation got changed in https://github.com/rust-lang/rust/pull/117525 without updating the comment. Now the comment makes no sense any more since there is no intrinsic that returns a pointer in this function any more.
(It is also very strange to say "in the new version" in a comment -- what is that supposed to tell someone reading the code 2 years later? That wording was introduced even earlier, in https://github.com/rust-lang/rust/pull/109179.)
Cc `@GKFX` `@petrochenkov` `@llogiq` `@scottmcm`
|
|
Miri subtree update
r? `@ghost`
|
|
Don't consider unstable fields always-inhabited
This reverts the hack in https://github.com/rust-lang/rust/pull/133889 now that `Pin`'s field is no longer public.
Fixes https://github.com/rust-lang/rust/issues/143468.
r? ```@compiler-errors```
|
|
Add non-regression test for #144168
This is a non-regression test for issue rust-lang/rust#144168, reduced from `zerocopy`, to go with https://github.com/rust-lang/rust/pull/144172 since it had no test yet, and we didn't want to delay it from landing.
Closes rust-lang/rust#144168
I've checked that the test does fail without rust-lang/rust#144172.
|
|
r=compiler-errors
Debug impls for DropElaborators
It's a little weird that these just have a completely empty Debug impl. Now they're `ElaborateDropsCtxt { .. }` and `DropShimElaborator { .. }`.
|
|
opt-dist: change build_dir field to be an actual build dir
make it configurable so users can set build.build-dir option in bootstrap.toml
r? Kobzol
try-job: dist-x86_64-msvc
try-job: dist-x86_64-linux
|
|
tests: Skip supported-crate-types test on musl hosts
This test depends on the target-specific default of crt-static for musl targets. However, running the testsuite on a musl host requires setting `crt-static` to `false`, as it wouldn't otherwise be possible to build rustc. This in turn will enable `-Ctarget-feature=-crt-static` for all tests, mismatching the expected `+crt-static` for the musl target tested in this testcase.
Since this test specifically tests the default value of `crt-static` for the musl target, ignoring it entirely makes more sense than manually setting `-Ctarget-feature=+crt-static` here, but both would be valid approaches.
|
|
Ban projecting into SIMD types [MCP838]
Closes https://github.com/rust-lang/compiler-team/issues/838
The actual compiler change here is tiny; there's just a bazillion tests to update.
~~Since I'm sure I've missed some, for now~~
~~r ghost~~
try-job: test-various
try-job: x86_64-gnu-nopt
|
|
On musl hosts, we already set -Ctarget-feature=-crt-static and
IS_MUSL_HOST=1 in compiletest. However, in order for the run-make tests
to compile fine on musl hosts, we need to propagate this flag in our
rustc invocations to ensure we can generate cdylibs.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
Consider param-env for sizedness fast path
Look up `T: Sized` in param-env if `T` is a param or placeholder (the latter is for use in the new solver).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
make it configurable so users can set build.build-dir option in bootstrap.toml
|
|
|
|
|
|
|
|
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
r? dep-bumps
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 15 packages to latest compatible versions
Updating chrono-tz v0.10.3 -> v0.10.4
Removing chrono-tz-build v0.4.1
Updating clap v4.5.40 -> v4.5.41
Updating clap_builder v4.5.40 -> v4.5.41
Updating clap_derive v4.5.40 -> v4.5.41
Updating crc32fast v1.4.2 -> v1.5.0
Updating derive_setters v0.1.7 -> v0.1.8
Updating libredox v0.1.4 -> v0.1.6
Updating measureme v12.0.1 -> v12.0.3
Removing parse-zoneinfo v0.3.1
Adding phf v0.12.1
Adding phf_shared v0.12.1
Updating rustix v1.0.7 -> v1.0.8
Updating serde_json v1.0.140 -> v1.0.141
Updating sysinfo v0.36.0 -> v0.36.1
Updating wasi-preview1-component-adapter-provider v34.0.1 -> v34.0.2
Updating winnow v0.7.11 -> v0.7.12
note: pass `--verbose` to see 39 unchanged dependencies behind latest
library dependencies:
Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 3 unchanged dependencies behind latest
rustbook dependencies:
Locking 13 packages to latest compatible versions
Updating ammonia v4.1.0 -> v4.1.1
Updating cc v1.2.29 -> v1.2.30
Updating clap v4.5.40 -> v4.5.41
Updating clap_builder v4.5.40 -> v4.5.41
Updating clap_complete v4.5.54 -> v4.5.55
Updating clap_derive v4.5.40 -> v4.5.41
Updating crc32fast v1.4.2 -> v1.5.0
Updating html5ever v0.31.0 -> v0.35.0
Updating markup5ever v0.16.2 -> v0.35.0
Updating match_token v0.1.0 -> v0.35.0
Updating rustix v1.0.7 -> v1.0.8
Updating serde_json v1.0.140 -> v1.0.141
Updating winnow v0.7.11 -> v0.7.12
```
|
|
This reverts the hack in https://github.com/rust-lang/rust/pull/133889
now that `Pin`'s field is no longer public.
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#143282 (Add `uX::strict_sub_signed`)
- rust-lang/rust#143423 (address clippy formatting nits)
- rust-lang/rust#143720 (Allow `Rvalue::Repeat` to return true in `rvalue_creates_operand` too)
- rust-lang/rust#144011 (bootstrap: Don't trigger an unnecessary LLVM build from check builds)
- rust-lang/rust#144112 (bootstrap: Ignore `rust.debuginfo-level-tests` for codegen tests)
- rust-lang/rust#144125 (Add new `ignore-backends` and `needs-backends` tests annotations)
- rust-lang/rust#144143 (Fix `-Ctarget-feature`s getting ignored after `crt-static`)
- rust-lang/rust#144150 (tests: assembly: cstring-merging: Disable GlobalMerge pass)
- rust-lang/rust#144190 (Give a message with a span on MIR validation error)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Give a message with a span on MIR validation error
It was handy to get a source+line link for rust-lang/rust#143833, even if it's just to the function and not necessarily to the statement.
r? mir
|
|
tests: assembly: cstring-merging: Disable GlobalMerge pass
The test relies on LLVM not merging all the globals into one and would currently otherwise fail on powerpc64le.
See https://github.com/llvm/llvm-project/blob/release/20.x/llvm/lib/CodeGen/GlobalMerge.cpp and here's the assembly generated prior to disabling the pass:
<details>
<summary>Expand me</summary>
```asm
.abiversion 2
.file "cstring_merging.5aa81ea7b99b31fe-cgu.0"
.section .text.cstr,"ax",``@progbits``
.globl cstr
.p2align 4
.type cstr,``@function``
cstr:
.Lfunc_begin0:
.cfi_startproc
.Lfunc_gep0:
addis 2, 12, .TOC.-.Lfunc_gep0@ha
addi 2, 2, .TOC.-.Lfunc_gep0@l
.Lfunc_lep0:
.localentry cstr, .Lfunc_lep0-.Lfunc_gep0
addis 3, 2, .L_MergedGlobals@toc@ha
li 4, 4
addi 3, 3, .L_MergedGlobals@toc@l
addi 3, 3, 4
blr
.long 0
.quad 0
.Lfunc_end0:
.size cstr, .Lfunc_end0-.Lfunc_begin0
.cfi_endproc
.section .text.manual_cstr,"ax",``@progbits``
.globl manual_cstr
.p2align 4
.type manual_cstr,``@function``
manual_cstr:
.Lfunc_begin1:
.cfi_startproc
.Lfunc_gep1:
addis 2, 12, .TOC.-.Lfunc_gep1@ha
addi 2, 2, .TOC.-.Lfunc_gep1@l
.Lfunc_lep1:
.localentry manual_cstr, .Lfunc_lep1-.Lfunc_gep1
addis 3, 2, .L_MergedGlobals@toc@ha
li 4, 4
addi 3, 3, .L_MergedGlobals@toc@l
addi 3, 3, 8
blr
.long 0
.quad 0
.Lfunc_end1:
.size manual_cstr, .Lfunc_end1-.Lfunc_begin1
.cfi_endproc
.type CSTR,``@object``
.section .data.rel.ro.CSTR,"aw",``@progbits``
.globl CSTR
.p2align 3, 0x0
CSTR:
.quad .L_MergedGlobals
.size CSTR, 8
.type .L_MergedGlobals,``@object``
.section .rodata..L_MergedGlobals,"a",``@progbits``
.L_MergedGlobals:
.asciz "foo"
.asciz "bar"
.asciz "baz"
.size .L_MergedGlobals, 12
.set .Lanon.a643e9a6bba67b7953be2b5f96e0e802.0, .L_MergedGlobals
.size .Lanon.a643e9a6bba67b7953be2b5f96e0e802.0, 4
.set .Lanon.a643e9a6bba67b7953be2b5f96e0e802.1, .L_MergedGlobals+4
.size .Lanon.a643e9a6bba67b7953be2b5f96e0e802.1, 4
.set .Lanon.a643e9a6bba67b7953be2b5f96e0e802.2, .L_MergedGlobals+8
.size .Lanon.a643e9a6bba67b7953be2b5f96e0e802.2, 4
.ident "rustc version 1.90.0-dev"
.section ".note.GNU-stack","",``@progbits``
```
</details>
|
|
Fix `-Ctarget-feature`s getting ignored after `crt-static`
The current behaviour introduced by commit a50a3b8e318594c41783294e440d864763e412ef would discard any target features specified after `crt-static` (the only member of `RUSTC_SPECIFIC_FEATURES`). This is because it returned instead of continuing processing the next feature.
I wasn't entirely sure how the regression test should look like, but this one should do. If anyone has some suggestions, I'm happy to learn, it's my first test :)
I've confirmed that the test fails without the fix on `powerpc64le-unknown-linux-musl` and `x86_64-unknown-linux-gnu`.
cc ``@RalfJung``
|
|
Add new `ignore-backends` and `needs-backends` tests annotations
Part of https://github.com/rust-lang/compiler-team/issues/891.
Next step will be to add these annotations in the files where either the output is different based on the codegen (like `asm` tests) or that are known to fail in the GCC backend.
cc `@oli-obk` `@antoyo`
r? `@Kobzol`
|
|
bootstrap: Ignore `rust.debuginfo-level-tests` for codegen tests
As dicussed in https://github.com/rust-lang/rust/issues/61117#issuecomment-495587364, codegen tests typically depend on the raw LLVM IR output and are sensitive to debuginfo level. So do not apply `rust.debuginfo-level-tests` for codegen tests.
Before this commit:
$ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
test result: FAILED. 654 passed; 136 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.22s
After this commit:
$ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
NOTE: ignoring `rust.debuginfo-level-tests=2` for codegen tests
test result: ok. 790 passed; 0 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.21s
### Run this in CI?
Maybe it will make sense to add this to CI later but I think it is too early to do now before more non-codegen tests work with `rust.debuginfo-level-tests=2`.
|
|
bootstrap: Don't trigger an unnecessary LLVM build from check builds
Coming back to r-l/r development after a few weeks away, I found a major regression in my dev workflows: running `x check compiler` (either manually or via rust-analyzer) would have the side-effect of building LLVM, even though that shouldn't be necessary.
For my main build directory this would be a minor annoyance, but for my separate rust-analyzer build directory it's a huge problem because it causes a completely separate build of LLVM, which takes a long time and should be completely unnecessary.
---
After some investigation, I tracked down the problem to the `can_skip_build` check in this code:
https://github.com/rust-lang/rust/blob/3014e79f9c8d5510ea7b3a3b70d171d0948b1e96/src/bootstrap/src/core/build_steps/compile.rs#L1382-L1396
Historically, this would skip the LLVM build for stage 0 check builds. But after the recent stage 0 std redesign and some associated check stage renumbering (e.g. rust-lang/rust#143048), the condition `builder.top_stage == build_stage` is now false, because `top_stage` is 1 (due to the renumbering) but `build_stage` is 0 (because a “stage 1” non-library check build still uses the stage 0 compiler).
---
Because this is a critical contributor roadblock for me, I have tried to fix this in a relatively narrow way. It's possible that all of this surrounding logic could be greatly simplified (especially in light of the stage redesign changes), but I didn't want this fix to be held back by scope creep.
---
(Zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Bootstrap.20incorrectly.20building.20LLVM.20for.20check.20builds/near/528991035)
|
|
Allow `Rvalue::Repeat` to return true in `rvalue_creates_operand` too
The conversation in https://github.com/rust-lang/rust/pull/143502#discussion_r2189410911 made be realize how easy this is to handle, since the only possibilty is ZSTs -- everything else ends up with the destination being `LocalKind::Memory` and thus doesn't call `codegen_rvalue_operand` at all.
This gets us perilously close to a world where `rvalue_creates_operand` only ever returns true. (See rust-lang/rust#143860 for more.)
|
|
address clippy formatting nits
- int_log10.rs: change top level doc comments to outer
- collect.rs: remove empty line after doc comment
- clippy fix: markdown indentation for indented items after line break: a markdown list item continued over multiples lines, but those following lines which are part of the same item are not indented
- clippy fix: bound in one place: when there is a bound in angle brackets and another bound on the same variable in a where clause
|
|
Add `uX::strict_sub_signed`
rust-lang/rust#116090 missed `strict_sub_signed`, adding it here.
Part of rust-lang/rust#118260.
r? ``@m-ou-se``
|
|
|
