| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
local style
|
|
Update to LLVM 21.1.0
|
|
|
|
To unblock the Rust CI in PR [1], use a temporary commit from Rust for
Linux that supports the future target spec format.
Link: https://github.com/rust-lang/rust/pull/144443 [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
|
|
|
|
rustdoc: a few micro-optimizations targeted at build_impl
Unsure if these will be anything substantial, but the first one at least should git rid of quite a few branches, second one unsure if it's worth it.
r? `@GuillaumeGomez`
|
|
fix: In highlight_related, when on an unsafe block, don't highlight unsafe operations of other unsafe blocks
|
|
|
|
Update cargo submodule
3 commits in 623d536836b4cde09ce38609232a024d5b25da81..a6c58d43051d01d83f55a3e61ef5f5b2b0dd6bd9
2025-08-22 19:05:52 +0000 to 2025-08-26 23:05:12 +0000
- test: avoid hardcoded target spec json (rust-lang/cargo#15880)
- test(add): Cover some frontmatter corner cases (rust-lang/cargo#15886)
- Add more context to publish-failed error message (rust-lang/cargo#15879)
r? ghost
|
|
|
|
|
|
Inherit TCC in debuginfo tests on macOS
macOS has a system for propagating folder permissions, which LLDB disables when spawning processes, which in turn causes debuginfo tests to spam the user with repeated pop-ups asking for permissions. See the code comment for details, as well as the following video for an example of how this looks in practice:
https://github.com/user-attachments/assets/1e54f5b8-9130-4b59-8e92-1db1e58fb361
I stumbled upon the incantation to fix this (`settings set target.inherit-tcc true`) while investigating slowdowns when spawning newly created binaries due to XprotectService, see [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20scripts.20slow.20on.20macOS.3F).
This would allow me to no longer have a `build.build-dir = "/Users/madsmtm/rust-build"` workaround in my `bootstrap.toml`.
|
|
Introduce a `[workspace.dependencies`] section in the top-level `Cargo.toml`
It lets us avoid a lot of repetition of crate versions, etc.
I've just done a few as a start. Many more can be done in follow-ups.
r? `@Kobzol`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Move `riscv64-gc-unknown-linux-musl` from Tier 2 with Host tools to Tier 2
It is not shipped with host tools, so it was located in the wrong group. The musl target is [here](https://github.com/rust-lang/rust/blob/467c89cd0b1c579edc247808c35941677918d29d/src/ci/docker/host-x86_64/dist-various-2/Dockerfile#L126) - no host tools.
Noticed in https://github.com/rust-lang/docker-rust/pull/247.
|
|
Move WTF-8 code from std into core and alloc
This is basically a small portion of rust-lang/rust#129411 with a smaller scope. It *does not*\* affect any public APIs; this code is still internal to the standard library. It just moves the WTF-8 code into `core` and `alloc` so it can be accessed by `no_std` crates like `backtrace`.
> \* The only public API this affects is by adding a `Debug` implementation to `std::os::windows::ffi::EncodeWide`, which was not present before. This is due to the fact that `core` requires `Debug` implementations for all types, but `std` does not (yet) require this. Even though this was ultimately changed to be a wrapper over the original type, not a re-export, I decided to keep the `Debug` implementation so it remains useful.
Like we do with ordinary strings, the tests are still located entirely in `alloc`, rather than splitting them into `core` and `alloc`.
----
Reviewer note: for ease of review, this is split into three commits:
1. Moving the original files into their new "locations"
2. Actually modifying the code to compile.
3. Removing aesthetic changes that were made so that the diff for commit 2 was readable.
You can review commits 1 and 3 to verify these claims, but commit 2 contains the majority of the changes you should care about.
----
API changes: `impl Debug for std::os::windows::ffi::EncodeWide`
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 269d5b56bcfdf2be82213e72ef9a2e4c592a8c6b
Filtered ref: a221b1d3ebb78ec8a01dcb1fe6bb165378e2f5c9
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to 269d5b56bcfdf2be82213e72ef9a2e4c592a8c6b.
|
|
perf: Cache trait solving across queries in the same revision
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#144499 (ci: Begin running ui tests with `rust.debuginfo-level-tests=1`)
- rust-lang/rust#145790 (Improve dist for gnullvm hosts)
- rust-lang/rust#145792 (Use attribute name in message for "outer attr used as inner attr" errors)
- rust-lang/rust#145840 (rustc_codegen_ssa: More comprehensive RISC-V ELF flags)
- rust-lang/rust#145876 (Enable building/disting standard library in stage 0)
- rust-lang/rust#145887 (bootstrap: Don't panic if codegen-backends is set to empty)
- rust-lang/rust#145888 (platform-support: Fix LoongArch32 host column)
- rust-lang/rust#145892 (add a flag to codegen fn attrs for foreign items)
- rust-lang/rust#145901 (Fix typo in comment of library/alloc/src/raw_vec/mod.rs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add a flag to codegen fn attrs for foreign items
r? `@ghost`
refiled to rerun CI
|
|
platform-support: Fix LoongArch32 host column
|
|
bootstrap: Don't panic if codegen-backends is set to empty
It fixes a bug we encountered in our last GCC backend sync: https://github.com/rust-lang/rustc_codegen_gcc/actions/runs/17214525469/job/48834700055?pr=753#step:18:595
In short, we used to have in `bootstrap.toml` an empty `rust.codegen-backends = []`, triggering the `unwrap`. We fixed it in https://github.com/rust-lang/rustc_codegen_gcc/pull/753/commits/ad99858fd9056bd29e96898be0f5e01ef527a092.
r? `@Kobzol`
|
|
Enable building/disting standard library in stage 0
After the stage0 redesign, building a stage0 library no longer is a thing, because the stage0 compiler normally cannot build libstd anymore. However, there are valid use-cases for having the ability to quickly cross-compile libstd for different targets, when the stage0 compiler is e.g. a stable released version, and you want to cross-compile libstd from the same sources of that compiler.
This PR allows that, as long as you set `build.local-rebuild = true`, which promises bootstrap that the stage0 compiler actually comes from in-tree sources, and can thus compile libstd.
The change needed to enable this is very minimal, so I think that it is worth it to allow this use-case to work.
Fixes: https://github.com/rust-lang/rust/issues/145587
Fixes: https://github.com/rust-lang/rust/issues/145859
Related issue: https://github.com/rust-lang/rust/issues/94781
r? `@jieyouxu`
|
|
Improve dist for gnullvm hosts
LLVM tools cross-compilation has been fixed by rust-lang/rust#145763 and LLVM downloading from CI no longer causes build error, so let's enable them both.
|
|
ci: Begin running ui tests with `rust.debuginfo-level-tests=1`
To reduce risk of regressing on generating debuginfo e.g. in the form of ICE:s. This will also ensure that future ui tests work with different debuginfo levels. See https://github.com/rust-lang/rust/issues/61117.
When I looked at run time for different CI jobs, **x86_64-gnu-debug** was far from the bottleneck, so it should be fine to make it perform more work.
A handful of tests are failing so we need to force debuginfo=0 on those for now.
We'll start small with debuginfo=1. We'll step up to debuginfo=2 once most (all?) tests can handle debuginfo=1. There are more failures with debuginfo=2 than with debuginfo=1.
|
|
It is not shipped with host tools, so it was located in the wrong group.
|
|
|
|
r=GuillaumeGomez
GCC backend subtree update
cc `@antoyo`
r? ghost
|
|
operations of other unsafe blocks
|
|
|
|
|
|
|
|
Replace it with normal `SolverDefId::TypeAliasId`.
The split caused a very funny bug where code was getting `TypeAliasId` where it expected `ForeignId`, because `TypeAliasId` had a `From` impl from `hir_def::TypeAliasId` and `ForeignId` had not, plus a careless `into()`.
I could've fixed this specific bug but opted to remove the split instead; currently, it just provides more room for bugs, as we don't have typed IDs for the solver anyway, and even when we'll have (hopefully), that doesn't seem like a very useful distinction, for example in hir-def foreign types are just `TypeAliasId` with some flags.
Constructing a test for this isn't trivial; the trivial test (creating a foreign type, even proving a trait bound for it) fails to fail before the change, probably because we don't use the new solver everywhere yet so we don't trigger this specific code path.
|
