| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix rustc uplifting (take two)
The rustc uplifting logic is really annoying.. https://github.com/rust-lang/rust/pull/145557 was not enough to fix it.
Consider https://github.com/rust-lang/rust/issues/145534#issuecomment-3201868888: in this situation, we do a stage3 build of a cross-compiled rustc (it happens because we run `x test --stage 2`, which mistakenly builds a stage3 rustc, but it doesn't matter what casuses it, what matters is that the stage3 build isn't working).
Currently, a stage3 cross-compiled build of rustc works like this:
1) stage0 (host) -> stage1 (host)
2) stage1 (host) -> stage2 (host)
3) stage2 (host) -> stage3 (target)
The problem is that in the uplifting logic, I assumed that we will have a stage2 (target) rustc available, which we can uplift. And that would indeed be an ideal solution. But currently, we will actually build a stage2 (*host*) rustc, and only then start the cross-compilation. So the uplifting is broken.
I spend a couple of hours trying to fix this, and do the uplifting "from the other direction", so that already when we assemble a stage3 rustc, we notice that an uplift should happen, and we only build stage1 (host) rustc, which also helps avoid one needless rustc build. However, this was relatively complicated and would require larger changes that I was not confident landing at this time.
So instead I decided to do a much simpler fix, and just disable rustc uplifting when cross-compiling. Since we currently do the `stage2 (host) -> stage3 (target)` step, it should not actually affect stage3 cross-compiled builds in any way (I hope..), and should only affect stage4+ builds, about which I don't really care (the only change there should be more rustc builds). For normal builds, the stage2 host rustc should (hopefully) always be present, so we shouldn't run into this issue.
Eventually, I would like to remove rustc uplifting completely. However, `x test --stage 2` on CI still currently builds a stage3 rustc for some reason, and if we removed uplifting completely, even for non-cross-compiled builds, that would cause an additional rustc build, and that's not great. So for now let's just allow uplifting for non-cross-compiled builds.
Fixes rust-lang/rust#145534.
r? `@jieyouxu`
|
|
|
|
add a fallback implementation for the `prefetch_*` intrinsics
related ACP: https://github.com/rust-lang/libs-team/issues/638
The fallback is to just ignore the arguments. That is a valid implementation because this intrinsic is just a hint.
I also added the `miri::intrinsic_fallback_is_spec` annotation, so that miri now supports these operations. A prefetch intrinsic call is valid on any pointer. (specifically LLVM guarantees this https://llvm.org/docs/LangRef.html#llvm-prefetch-intrinsic)
Next, I made the `LOCALITY` argument a const generic. That argument must be const (otherwise LLVM crashes), but that was not reflected in the type.
Finally, with these changes, the intrinsic can be safe and `const` (a prefetch at const evaluation time is just a no-op).
cc `@Amanieu`
r? `@RalfJung`
|
|
r=lolbinarycat
Fix bug where `rustdoc-js` tester would not pick the right `search.js` file if there is more than one
It happened to me quite a few times recently when I worked on the search index:
1. I make a change in search.js
2. I run `rustdoc-js` tests
3. nothing changes
So my solution was to simply remove the folder, but it's really suboptimal. With this PR, it now picks the most recently modified file.
cc ```@lolbinarycat```
|
|
r=Kobzol,madsmtm
Demote x86_64-apple-darwin to Tier 2 with host tools
Switch to only using aarch64 runners (implying we are now cross-compiling) and stop running tests. In the future, we could enable (some?) tests via Rosetta 2.
This implements the decision from https://github.com/rust-lang/rfcs/pull/3841.
|
|
mention lint group in default level lint note
### Summary
This PR updates lint diagnostics so that default-level notes now mention the lint group they belong to, if any.
Fixes: rust-lang/rust#65464.
### Example
```rust
fn main() {
let x = 5;
}
```
Before:
```
= note: `#[warn(unused_variables)]` on by default
```
After:
```
= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default
```
### Unchanged Cases
Messages remain the same when the lint level is explicitly set, e.g.:
* Attribute on the lint `#[warn(unused_variables)]`:
```
note: the lint level is defined here
LL | #[warn(unused_variables)]
| ^^^^^^^^^^^^^^^^
```
* Attribute on the group `#[warn(unused)]:`:
```
= note: `#[warn(unused_variables)]` implied by `#[warn(unused)]`
```
* CLI option `-W unused`:
```
= note: `-W unused-variables` implied by `-W unused`
= help: to override `-W unused` add `#[allow(unused_variables)]`
```
* CLI option `-W unused-variables`:
```
= note: requested on the command line with `-W unused-variables`
```
|
|
r=notriddle
Rustdoc: typecheck scrape-examples.js
more typechecking progress, this time we're mostly held back by the fact that `document.querySelectorAll` can't return nice types if its given a compound query (see the issue linked in a code comment).
Additionally, it seems like the generated `data-locs` attribute has fields that are never used by anything?
r? ```@notriddle```
|
|
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#145538 (bufreader::Buffer::backshift: don't move the uninit bytes)
- rust-lang/rust#145542 (triagebot: Don't warn no-mentions on subtree updates)
- rust-lang/rust#145549 (Update rust maintainers in openharmony.md)
- rust-lang/rust#145550 (Avoid using `()` in `derive(From)` output.)
- rust-lang/rust#145556 (Allow stability attributes on extern crates)
- rust-lang/rust#145560 (Remove unused `PartialOrd`/`Ord` from bootstrap)
- rust-lang/rust#145568 (ignore frontmatters in `TokenStream::new`)
- rust-lang/rust#145571 (remove myself from some adhoc-groups and pings)
- rust-lang/rust#145576 (Add change tracker entry for `--timings`)
- rust-lang/rust#145578 (Add VEXos "linked files" support to `armv7a-vex-v5`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
Rollup of 15 pull requests
Successful merges:
- rust-lang/rust#145338 (actually provide the correct args to coroutine witnesses)
- rust-lang/rust#145429 (Couple of codegen_fn_attrs improvements)
- rust-lang/rust#145452 (Do not strip binaries in bootstrap everytime if they are unchanged)
- rust-lang/rust#145464 (Stabilize `const_pathbuf_osstring_new` feature)
- rust-lang/rust#145474 (Properly recover from parenthesized use-bounds (precise capturing lists) plus small cleanups)
- rust-lang/rust#145486 (Fix `unicode_data.rs` mention message)
- rust-lang/rust#145490 (Trace some basic I/O operations in bootstrap)
- rust-lang/rust#145493 (remove `should_render` in `PrintAttribute` derive)
- rust-lang/rust#145500 (Port must_use to the new target checking)
- rust-lang/rust#145505 (Simplify span caches)
- rust-lang/rust#145510 (Visit and print async_fut local for async drop.)
- rust-lang/rust#145511 (Rust build fails on OpenBSD after using file_lock feature)
- rust-lang/rust#145532 (resolve: debug for block module)
- rust-lang/rust#145533 (Reorder `lto` options from most to least optimizing)
- rust-lang/rust#145537 (Do not consider a `T: !Sized` candidate to satisfy a `T: !MetaSized` obligation.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
The fallback is to just ignore the arguments. That is a valid implementation because this intrinsic is just a hint.
I also added `miri::intrinsic_fallback_is_spec` annotation, so that miri now supports these operations. A prefetch intrinsic call is valid on any pointer.
|
|
|
|
if there is more than one
|
|
Add change tracker entry for `--timings`
Follow-up to rust-lang/rust#145379. Forgor when reviewing.
r? `@Kobzol`
|
|
Remove unused `PartialOrd`/`Ord` from bootstrap
It was just wasting compile-time. There is one remaining "old" bootstrap test that uses the `Ord` impl on one test step, I'll remove that later.
|
|
Update rust maintainers in openharmony.md
|
|
Reorder `lto` options from most to least optimizing
This is a follow up to https://github.com/rust-lang/cargo/pull/15841.
`@weihanglo` pointed out the original order of the `lto` options in the Cargo book was consistent with https://doc.rust-lang.org/rustc/codegen-options/index.html?highlight=lto#lto.
The options in the Cargo book have since been reordered. This PR keeps the two references consistent.
|
|
Trace some basic I/O operations in bootstrap
When working on removing the rmeta sysroot copies, it is quite difficult to figure out *why* was did a certain file appear in a given directory. This should help with that a bit.
r? `@jieyouxu`
|
|
Do not strip binaries in bootstrap everytime if they are unchanged
I was profiling bootstrap to figure out why a no-op build takes upward of two seconds on my machine. I found that half of that is Cargo (which is mostly unavoidable) and the rest (~900ms) is running strip. We don't need to restrip already stripped binaries all the time.
r? `@jieyouxu`
|
|
Couple of codegen_fn_attrs improvements
As noted in https://github.com/rust-lang/rust/pull/144678#discussion_r2245060329 here is no need to keep link_name and export_name separate, which the third commit fixes by merging them. The second commit removes some dead code and the first commit merges two ifs with equivalent conditions. The last commit is an unrelated change which removes an unused `feature(autodiff)`.
|
|
Miri: fix handling of in-place argument and return place handling
This fixes two separate bugs (in two separate commits):
- If the return place is `_local` and not `*ptr`, we didn't always properly protect it if there were other pointers pointing to that return place.
- If two in-place arguments are *the same* local variable, we didn't always detect that aliasing.
|
|
Add tracing to various miscellaneous functions
This PR adds tracing to:
- `ty.fn_sig()`. There is only one place where `fn_sig` is called for real within `rustc_const_eval`. There are three other places where it's called, but one is inside `ConstCx::fn_sig` (which does not seem to be used anywhere), another is under `if cfg!(debug_assertions)`, and the last is within `call_main` and thus gets called only once.
- the two possible things `find_mir_or_eval_fn` can do: "emulate_foreign_item" and "load_mir"
- all calls to `Const.eval()` within the Miri or the `rustc_const_eval` codebase.
- a separate commit also fixes the style of some tracing macros
Those are all quite long-lived operations, that in total make up for 6-7% of the total time spent in the program. I found out about them by looking for long periods of time that were previously not traced at all, using this SQL query in ui.perfetto.dev:
```sql
with ordered as (select s1.*, row_number() over (order by s1.ts) as rn from slices as s1 where s1.parent_id is null and s1.dur > 0 and s1.name != "frame" and s1.name != "step" and s1.name != "backtrace") select a.ts+a.dur as ts, b.ts-a.ts-a.dur as dur, a.id, a.track_id, a.category, a.depth, a.stack_id, a.parent_stack_id, a.parent_id, a.arg_set_id, a.thread_ts, a.thread_instruction_count, a.thread_instruction_delta, a.cat, a.slice_id, "empty" as name from ordered as a inner join ordered as b on a.rn=b.rn-1 /*where b.ts-a.ts-a.dur > 5000*/ order by b.ts-a.ts-a.dur desc
```
<details>
<summary>How the table was obtained</summary>
The above image was obtained in ui.perfetto.dev with the following SQL query after obtaining a trace file by running Miri on the following Rust code with `n=100`.
```sql
select "TOTAL PROGRAM DURATION" as name, count(*), max(ts + dur) as "sum(dur)", 100.0 as "%", null as "min(dur)", null as "max(dur)", null as "avg(dur)", null as "stddev(dur)" from slices union select "TOTAL OVER ALL SPANS (excluding events)" as name, count(*), sum(dur), cast(cast(sum(dur) as float) / (select max(ts + dur) from slices) * 1000 as int) / 10.0 as "%", min(dur), max(dur), cast(avg(dur) as int) as "avg(dur)", cast(sqrt(avg(dur*dur)-avg(dur)*avg(dur)) as int) as "stddev(dur)" from slices where parent_id is null and name != "frame" and name != "step" and dur > 0 union select name, count(*), sum(dur), cast(cast(sum(dur) as float) / (select max(ts + dur) from slices) * 1000 as int) / 10.0 as "%", min(dur), max(dur), cast(avg(dur) as int) as "avg(dur)", cast(sqrt(avg(dur*dur)-avg(dur)*avg(dur)) as int) as "stddev(dur)" from slices where parent_id is null and name != "frame" and name != "step" group by name order by sum(dur) desc, count(*) desc
```
```rust
fn main() {
let n: usize = std::env::args().nth(1).unwrap().parse().unwrap();
let mut v = (0..n).into_iter().collect::<Vec<_>>();
for i in &mut v {
*i += 1;
}
}
```
</details>
<img width="1689" height="317" alt="image" src="https://github.com/user-attachments/assets/ee2c81f5-d74a-4da5-b4b6-ab2770175b14" />
|
|
run spellcheck as a tidy extra check in ci
This is probably how it should've been done from the start.
r? ``@Kobzol``
|
|
Require approval from t-infra instead of t-release on tier bumps
Discussed at https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Tier.201.20target.20promotion.20RFC.20FCP.20sign-offs/with/532735844.
I also changed "viability and value" to just "viability". I think that t-infra should decide whether it's viable to support a given target on our CI. The value should be determined by t-compiler.
r? ``@jieyouxu``
|
|
Add `-Zindirect-branch-cs-prefix`
Cc: ``@azhogin`` ``@Darksonn``
This goes on top of https://github.com/rust-lang/rust/pull/135927, i.e. please skip the first commit here. Please feel free to inherit it there.
In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.
There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.
Tracking issue: https://github.com/rust-lang/rust/issues/116852.
MCP: https://github.com/rust-lang/compiler-team/issues/868.
|
|
Extend `QueryStability` to handle `IntoIterator` implementations
This PR extends the `rustc::potential_query_instability` lint to check values passed as `IntoIterator` implementations.
Full disclosure: I want the lint to warn about this line (please see #138871 for why): https://github.com/rust-lang/rust/blob/aa8f0fd7163a2f23aa958faed30c9c2b77b934a5/src/librustdoc/json/mod.rs#L261
However, the lint warns about several other lines as well.
Final note: the functions `get_callee_generic_args_and_args` and `get_input_traits_and_projections` were copied directly from [Clippy's source code](https://github.com/rust-lang/rust/blob/4fd8c04da0674af2c51310c9982370bfadfa1b98/src/tools/clippy/clippy_lints/src/methods/unnecessary_to_owned.rs#L445-L496).
|
|
|
|
Improve context of bootstrap errors in CI
Inspired by https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/printing.20test.20suite.20name.20by.20default/with/534920583, this PR attempts to improve the context displayed when a bootstrap invocation fails in CI.
Since https://github.com/rust-lang/rust/pull/145261, we now see the latest started step when a failure occurs. However, we can go further.
1) The first commit prints the actual executed bootstrap invocation command arguments when bootstrap ends. Since CI jobs often run multiple bootstrap commands, this makes it easier to figure out which one of them failed (before it was annoying having to search for that in CI logs). Because bootstrap doesn't really use `Result`s much, and most of them time it ends with the `detail_exit` function, which YOLOs `std::process::exit(...)`, I added the print there.
2) Adds `#[track_caller]` to a few bootstrap Cargo builder functions. This makes the log that we print when a command fails more accurate:
```
2025-08-16T18:18:51.6998201Z Command ... failed ...
2025-08-16T18:18:51.7003653Z Created at: src/bootstrap/src/core/builder/cargo.rs:423:33
2025-08-16T18:18:51.7004032Z Executed at: src/bootstrap/src/core/build_steps/doc.rs:933:26
```
Before, the `cargo.rs:XYZ` location wasn't very useful.
3) Is the most wild thing (I'll revert if you find it too magical). We store the step stack of the currently active `Builder` instance in a global variable, and when bootstrap exits with a failure, we print the stack, to make it easier to find out what was happening when a failure occurred. We could print an actual captured `Backtrace`, but I think that would be too much information in the common case. We now pass `RUST_BACKTRACE=1` on CI, so if bootstrap actually crashes unexpectedly, we would see the stacktrace.
The end of the bootsrap failure log in CI now looks like this now:
```
Bootstrap failed while executing `x build library`
---BOOTSTRAP step stack start---
Assemble { target_compiler: Compiler { stage: 1, host: x86_64-unknown-linux-gnu, forced_compiler: false } }
Rustc { target: x86_64-unknown-linux-gnu, build_compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu, forced_compiler: false }, crates: [] }
---BOOTSTRAP step stack end---
```
r? `@jieyouxu`
|
|
Fix uplifting in `Assemble` step
In https://github.com/rust-lang/rust/pull/145310, I removed [this line](https://github.com/rust-lang/rust/pull/145310/files#diff-5a1e05f2688d271039171a547d407d0c8a96715ee64d35562fc76b4c9a874303L2109), which adjusted the stage of the build compiler if an uplift has happened. This broke stage3+ uplifted rustc builds (https://github.com/rust-lang/rust/issues/145534). I could swear I tested this in the PR, but somehow I missed it.
Instead of keeping the original returned stage, I made it more explicit by returning the actually used `build_compiler` from the `Rustc` step, and then use that in the `Assemble` step.
The changes to `RustcLink` were needed to fix `ui-fulldeps`, which apparently build a stage3 rustc, because I haven't fixed the test steps yet :sweat_smile:
Hopefully we might be able to remove `RustcLink` if the approach from https://github.com/rust-lang/rust/pull/144252 will work.
Should fix https://github.com/rust-lang/rust/issues/145534.
r? ``@jieyouxu``
|
|
r=lolbinarycat,GuillaumeGomez
rustdoc-search: search backend with partitioned suffix tree
Before:
- https://notriddle.com/windows-docs-rs/doc-old/windows/
- https://doc.rust-lang.org/1.89.0/std/index.html
- https://doc.rust-lang.org/1.89.0/nightly-rustc/rustc_hir/index.html
After:
- https://notriddle.com/windows-docs-rs/doc/windows/
- https://notriddle.com/rustdoc-html-demo-12/stringdex/doc/std/index.html
- https://notriddle.com/rustdoc-html-demo-12/stringdex/compiler-doc/rustc_hir/index.html
## Summary
Rewrites the rustdoc search engine to use an indexed data structure, factored out as a crate called [stringdex](https://crates.io/crates/stringdex), that allows it to perform modified-levenshtein distance calculations, substring matches, and prefix matches in a reasonably efficient, and, more importantly, *incremental* algorithm.
## Motivation
Fixes https://github.com/rust-lang/rust/issues/131156
While the windows-rs crate is definitely the worst offender, I've noticed performance problems with the compiler crates as well. It makes no sense for rustdoc-search to have poor performance: it's basically a spell checker, and those have been usable since the 90's.
Stringdex is particularly designed to quickly return exact matches, to always report those matches first, and to never, ever [place new matches on top of old ones](https://web.dev/articles/cls). It also tries to yield to the event loop occasionally as it runs. This way, you can click the exactly-matched result before the rest of the search finishes running.
## Explanation
A longer description of how name search works can be found in stringdex's [HACKING.md](https://gitlab.com/notriddle/stringdex/-/blob/main/HACKING.md) file.
Type search is done by performing a name search on each element, then performing bitmap operations to narrow down a list of potential matches, then performing type unification on each match.
## Drawbacks
It's rather complex, and takes up more disk space than the current flat list of strings.
## Rationale and alternatives
Instead of a suffix tree, I could've used a different [approximate matching data structure](https://en.wikipedia.org/wiki/Approximate_string_matching). I didn't do that because I wanted to keep the current behavior (for example, a straightforward trigram index won't match [oepn](https://doc.rust-lang.org/nightly/std/?search=oepn) like the current system does).
## Prior art
[Sherlodoc](https://github.com/art-w/sherlodoc) is based on a similar concept, but they:
- use edit distance over a suffix tree for type-based search, instead of the binary matching that's implemented here
- use substring matching for name-based search, [but not fuzzy name matching](https://github.com/art-w/sherlodoc/issues/21)
- actually implement body text search, which is a potential-future feature, but not implemented in this PR
## Future possibilities
### Low-level optimization in stringdex
There are half a dozen low-level optimizations that I still need to explore. I haven't done them yet, because I've been working on bug fixes and rebasing on rustdoc's side, and a more solid and diverse test suite for stringdex itself.
- Stringdex decides whether to bundle two nodes into the same file based on size. To figure out a node's size, I have to run compression on it. This is probably slower than it needs to be.
- Stack compression is limited to the same 256-slot sliding windows as backref compression, and it doesn't have to be. (stack and backref compression are used to optimize the representation of the edge pointer from a parent node to its child; backref uses one byte, while stack is entirely implicit)
- The JS-side decoder is pretty naive. It performs unnecessary hash table lookups when decoding compressed nodes, and retains a list of hashes that it doesn't need. It needs to calculate the hashes in order to construct the merkle tree correctly, but it doesn't need to keep them.
- Data compression happens at the end, while emitting the node. This means it's not being counted when deciding on how to bundle, which is pretty dumb.
### Improved recall in type-driven search
Right now, type-driven search performs very strict matching. It's very precise, but misses a lot of things people would want.
What I'm not sure about is whether to focus more on edit-distance-based approaches, or to focus on type-theoretical approaches. Both gives avenues to improve, but edit distance is going to be faster while type checking is going to be more precise.
For example, a type theoretical improvement would fix [`Iterator<T>, (T -> U) -> Iterator<U>`](https://doc.rust-lang.org/nightly/std/?search=Iterator%3CT%3E%2C%20(T%20-%3E%20U)%20-%3E%20Iterator%3CU%3E) to give [`Iterator::map`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.map), because it would recognize that the Map struct implements the Iterator trait. I don't know of any clean way to get this result to work without implementing significant type checking logic in search.js, and an edit-distance-based "dirty" approach would likely give a bunch of other results on top of this one.
## Full-text search
Once you've got this fuzzy dictionary matching to work, the logical next step is to implement some kind of information retrieval-based approach to phrase matching.
Like applying edit distance to types, phrase search gets you significantly better recall, but with a few major drawbacks:
- You have to pick between index bloat and the use of stopwords. Stopwords are bad because they might actually be important (try searching "if let" in mdBook if you're feeling brave), but without them, you spend a lot of space on text that doesn't matter.
- Example code also tends to have a lot of irrelevant stuff in it. Like stop words, we'd have to pick potentially-confusing or bloat.
Neither of these problems are deal-breakers, but they're worth keeping in mind.
|
|
Do not copy .rmeta files into the sysroot of the build compiler during check of rustc/std
Before, when bootstrap did a check build of rustc stage N (with a build compiler that was stage N-1), it automatically copied the resulting `.rmeta` artifacts into the sysroot of the stage N-1 build compiler, so that stage N `rustc_private` tools such as `miri` could be compiled using the stage N-1 build compiler. This has a number of issues:
- It was done unconditionally, even if no `rustc_private` tools were actually built.
- If we did a check and a build of the same stage compiler in the same bootstrap invocation, the generated rmeta and rlib files could clash. This is also why you can see that `check::Std` actually doesn't copy the artifacts anymore (which forced us to build std instead of just checking it in a bunch of `Check` steps).
- It was polluting the sysroot of the build compiler. This is especially annoying for the stage 0 compiler, because we are forced to create an artificial sysroot for it, so that we can copy new stuff into it.
- It was very implicit in bootstrap.
Based on suggestions by ```@cuviper``` and ```@bjorn3,``` I tried to change how this behaves. Instead of copying the rmeta artifacts into the sysroot of the build compiler (from where they would be loaded implicitly), they are now stored in a separate transient bootstrap build directory, and they are then explicitly passed *only* when checking `rustc_private` tools using the `-L` flag. The flags are passed out-of-band through our rustc wrapper, to avoid invalidating the build cache. This is the first commit.
The second commit does the same for std. For a few months, we used to build std instead of just checking it when doing a cross-compile check of something that required std, this now fixes it. There is still the previous ordering requirement though, that `check::Std` has to be executed as the last check step, or rather nothing that requires checked std should be executed *after* it, because it will run into rmeta/rlib duplications (https://github.com/rust-lang/rust/blob/4fa90ef7996f891f7f1e126411e5d75afe64accf/src/bootstrap/src/core/builder/mod.rs#L1066). I tried to fix in this PR, but it quickly runs into the fact that building things currently copies *rlib* artifacts into the build compiler sysroot. I want to fix that as one of the next steps. After we get rid of all the copies (or rather, we only do the copies for dist/stage2+ and do not copy anything into the stage0 compiler's sysroot), we could hopefully finally get rid of `stage0-sysroot`.
Based on my local tests, this seems to be working fine. If it works on CI, and we don't run into other issues after merging it, I'd like to do the same also for rlib artifacts generated during `x build`.
r? ```@jieyouxu```
|
|
Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]`
This came up during the sanitizer stabilization (rust-lang/rust#123617). Instead of a `#[no_sanitize(xyz)]` attribute, we would like to have a `#[sanitize(xyz = "on|off")]` attribute, which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off). The implementation is done according to what was [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Stabilize.20the.20.60no_sanitize.60.20attribute/with/495377292)).
The new attribute also works on modules, traits and impl items and thus enables usage as the following:
```rust
#[sanitize(address = "off")]
mod foo {
fn unsanitized(..) {}
#[sanitize(address = "on")]
fn sanitized(..) {}
}
trait MyTrait {
#[sanitize(address = "off")]
fn unsanitized_default(..) {}
}
#[sanitize(thread = "off")]
impl MyTrait for () {
...
}
```
r? ```@rcvalle```
|
|
ci: add timeout to windows disk cleanup wait
|
|
|
|
|
|
Also use tracing macro syntax instead of format()
|
|
expression is a local variable
|
|
Update cargo
28 commits in 840b83a10fb0e039a83f4d70ad032892c287570a..71eb84f21aef43c07580c6aed6f806a6299f5042
2025-07-30 13:59:19 +0000 to 2025-08-17 17:18:56 +0000
- update tests to match lint message changes from rust-lang/rust#140794 (rust-lang/cargo#15849)
- chore: downgrade to libc@0.2.174 (rust-lang/cargo#15851)
- Reorder `lto` options in profiles.md (rust-lang/cargo#15841)
- feat(unstable): add -Zbuild-analysis unstable feature (rust-lang/cargo#15845)
- refactor(unstable): group stabilized features (rust-lang/cargo#15846)
- Fixes error while running the cargo clippy --all-targets -- -D warning (rust-lang/cargo#15843)
- Clarify that `cargo doc --no-deps` is cumulative and won’t delete prev (rust-lang/cargo#15800)
- docs: Formatting and cross-linking to build-dir/target-dir docs (rust-lang/cargo#15840)
- Stabilize `build.build-dir` (rust-lang/cargo#15833)
- make resolve features public for cargo-as-a-library (rust-lang/cargo#15835)
- chore(deps): bump slab from 0.4.10 to 0.4.11 (rust-lang/cargo#15832)
- chore: remove x86_64-apple-darwin from CI and tests (rust-lang/cargo#15831)
- chore(deps): update msrv (3 versions) to v1.87 (rust-lang/cargo#15819)
- perf(package): Always reuse the workspace's target-dir (rust-lang/cargo#15783)
- More helpful error for invalid cargo-features = [] (rust-lang/cargo#15781)
- Add initial integration for `--json=timings` behing `-Zsection-timings` (rust-lang/cargo#15780)
- add is_inherited methods to InheritableDependency and InheritableField (rust-lang/cargo#15828)
- chore(deps): update compatible (rust-lang/cargo#15804)
- docs(unstable): Link out to the Plumbing commands effort (rust-lang/cargo#15821)
- chore(deps): update cargo-semver-checks to v0.43.0 (rust-lang/cargo#15825)
- test(build-std): relax the thread name assertion (rust-lang/cargo#15822)
- chore(deps): update msrv (1 version) to v1.89 (rust-lang/cargo#15815)
- Update semver tests for 1.89 (rust-lang/cargo#15816)
- Accessing each build script's `OUT_DIR` and in the correct order (rust-lang/cargo#15776)
- chore: bump to 0.92.0; update changelog (rust-lang/cargo#15807)
- docs: `-Zpackage-workspace` has been stabilized (rust-lang/cargo#15808)
- chore(deps): update rust crate cargo_metadata to 0.21.0 (rust-lang/cargo#15795)
- docs(build-rs): Fix broken intra-doc links (rust-lang/cargo#15810)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This removes the #[no_sanitize] attribute, which was behind an unstable
feature named no_sanitize. Instead, we introduce the sanitize attribute
which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off).
This also makes sanitize(kernel_address = ..) attribute work with
-Zsanitize=address
To do it the same as how clang disables address sanitizer, we now
disable ASAN on sanitize(kernel_address = "off") and KASAN on
sanitize(address = "off").
The same was added to clang in https://reviews.llvm.org/D44981.
|
|
|
|
Speedup `copy_src_dirs` in bootstrap
I was kinda offended by how slow it was. Just the `copy_src_dirs` part took ~3s locally in the `x dist rustc-src` step. In release mode it was just 1s, but that's kind of cheating (I wonder if we should build bootstrap in release mode on CI though...).
Did some basic optimizations to bring it down to ~1s also in debug mode.
Maybe it's overkill, due to https://github.com/rust-lang/rust/pull/145455. Up to you whether we should merge it or close it :)
r? `````````@jieyouxu`````````
|
