Rustup - #5252
Merged
Merged
Conversation
- Add rust_2018_idioms warn in Cargo.toml to catch elided lifetimes and other 2018-idiom lints, matching Miri crate-level lint policy. - Add ./x check src/tools/miri/priroda to bootstrap CI step. - Add cargo clippy --all-targets --locked -- -D warnings step to priroda CI job.
Usually avoid the sort in `WrappingRange::smallest_range_containing` I wasn't planning on touching this [again](rust-lang/rust#160198), but I had a shower thought: we've been sorting these [for a while](https://github.com/rust-lang/rust/pull/144577/changes#diff-122bc02528abab33fa6f367f937c00f22eb4d3dc95b6a83a807576b5271ca462R776) because that's better than doing a quadratic check for usable wraparound ranges, but actually we often don't need to. So long as the obvious `min..=max` range is small enough, we don't need to bother even looking for a wrapping range! Now, I don't think this code is particularly hot -- you'd need lots of enums or particularly big ones before it would really matter -- but this does let us short-circuit for even fairly complex enums like [mem::alignment](https://github.com/rust-lang/rust/blob/88f7399cb4912680976e1c342ea7661b9dc84940/library/core/src/mem/alignment.rs#L402-L435). ---
…gen_regions, r=BoxyUwU,lcnr trait_solver: normalize next-gen region constraints fixes rust-lang/rust#157729 -zassumptions-on-binders can produce next-gen region constraints that mean the same thing but don't have the same shape. in this case object candidate merging stayed ambiguous and instance resolution later hit the ice. imo normalizing the constraint at the response boundary is the least weird place for this, because candidate selection shouldn't need to know which vtable looks nicer. canonicalize and evaluate the next-gen region constraint before response canonicalization, then cover the dyn derived<p> supertrait case from the issue. lgtm locally with the focused test, tests/ui/traits/next-solver, and tests/ui/assumptions_on_binders. idk if there's a better home for the helper call, but ltm this keeps the fix pretty narrow.
Do not eagerly download rustfmt in bootstrap I'm continuing my bootstrap refactorings with the goal of avoiding eager download of stuff during config parsing, which makes the config parse step more complicated. An added benefit is that `rustfmt`, together with its `librustc_driver`, is now only downloaded on-demand. So unless you use `x fmt` or `x test tidy`, those two components won't be downloaded unnecessarily (both locally and on CI). Best reviewed commit-by-commit. r? @jieyouxu
mir: prohibit projection into scalable vec Fixes rust-lang/rust#160580. Preventing projections into scalable vectors is an oversight from the initial implementation and something we should fix. I'm surprised it caused a stdarch CI failure as reported by rust-lang/rust#160580, as nothing in rustc or stdarch seems to have changed that would have caused that to start happening as far as I can tell. This likely won't fix that stdarch CI failure if it keeps happening, because if there is a projection coming from somewhere then that needs to be fixed - nevertheless, preventing them as in this patch is the right thing to do. I've tested this against the stdarch CI locally.
…ffleLapkin MaybeDangling: ensure references fit inside the address space In the RFC we left open the question of the exact validity invariant for references inside `MaybeDangling`. This PR implements the strictest invariant I can think of: we already require references to be aligned, now we also require "addr + size" to be computable without overflow. This ensures that whatever niches we add to references in the future, `MaybeDangling` preserves those niches. Cc @rust-lang/opsem @WaffleLapkin Tracking issue: rust-lang/rust#118166 r? @oli-obk
Use recognizer functions for enums and tuple structs Non-urgent, but related to rust-lang/rust#160331 We currently shove most user defined types through `synthetic_lookup` as I hadn't gotten around to using type recognizers yet. If we want tests to skip outputting types when the type doesn't have a visualizer, we should also not attach a (useless) visualizer to most UDTs. The only things `synthetic_lookup` catches that aren't already caught by the regexes are tuple-structs and sum-type enums. This patch adds targeted type recognizers for those, and no longer sends types through `synthetic_lookup` at all on LLDB 19+ this doesn't affect `pretty-std.rs` since all those types have visualizers, but it will affect other tests if/when they're converted (e.g. `tests/debuginfo/struct-in-struct.rs`) r? @Kobzol, @jieyouxu
…r=mejrs Fix inaccurate description for crate and pathroot Same as https://github.com/bb1yd/rust/blob/8ab9fdff5a91b9f2b5ed57fb0275452d9a0d0280/compiler/rustc_resolve/src/diagnostics/impls.rs#L3027-L3035
Docs & bors: Replace mentions of libs-api with libs Per [the libs refactor RFC](rust-lang/rfcs#3984), libs-api will not exist anymore soon & so replace mentions of it with libs.
…r=joboet Fix references to unsupported on sys::paths::unix Compilation was seemingly broken by PR rust-lang/rust#150885, commit f2dd93228abcf29ab85960457df7a6f828eb3cb9, by removing one of the nested `mod`s. I'm one of the `armv7-sony-vita-newlibeabihf` target maintainers. Summary of changes for affected targets: - `armv7-sony-vita-newlibeabihf`: now compiles - `armv6k-nintendo-3ds`: still doesn't compile, apparently due to an issue introduced in rust-lang/rust#158168, which should be fixed by rust-lang/rust#160170 - all espidf targets: I haven't compiled any of them as I don't have the toolchain installed, but it should be on the same as 3DS. The same errors can be seen in [does-it-build](https://does-it-build.noratrieb.dev/build?nightly=2026-08-09&target=xtensa-esp32s3-espidf&mode=std)
Use `remove_dir_all` for `./x clean` This should work better in most cases (and be faster) particularly on Windows. I've left the old implementation more or less intact to provide diagnostics on failure. But it could be removed if desired.
…uwer Rollup of 9 pull requests Successful merges: - rust-lang/rust#158404 (trait_solver: normalize next-gen region constraints) - rust-lang/rust#160631 (Do not eagerly download rustfmt in bootstrap) - rust-lang/rust#160642 (mir: prohibit projection into scalable vec) - rust-lang/rust#160749 (MaybeDangling: ensure references fit inside the address space) - rust-lang/rust#160791 (Use recognizer functions for enums and tuple structs) - rust-lang/rust#160500 (Fix inaccurate description for crate and pathroot) - rust-lang/rust#160590 (Docs & bors: Replace mentions of libs-api with libs) - rust-lang/rust#160825 (Fix references to unsupported on sys::paths::unix) - rust-lang/rust#160852 (Use `remove_dir_all` for `./x clean`) Failed merges: - rust-lang/rust#160829 (bootstrap: Make `main.rs` a stub that calls into the library crate)
[Priroda] Add bootstrap test and check steps The priroda crate lives under src/tools/miri/priroda and shares miri's sysroot and toolchain setup, so register a test step that mirrors the existing miri one and a check step alongside cargo-miri. r? oli-obk
…anBrouwer Fix `visible_parent_map` fallback map merging perf regression This PR attempts to fix the `visible_parent_map` perf regression introduced in rust-lang/rust#160464, which was found in a [post-merge perf run](rust-lang/rust#160464 (comment)). Because the original PR fixes unnecessary iterations in the breadth-first search (BFS), meaning that it only reduces the amount of work during the BFS, the likely cause of the perf regression is the changed merging of the fallback map into the final visible parent map after the BFS. The goal of this PR is to determine whether this is the case through a perf try run. The change itself works around the Unord* APIs, but might be worth it to work around the perf regression.
Diagnostics ICE when replaying proof trees with next-solver When diagnostics replay proof tree state, rebuilding a canonical state can fail to match the current inference state. With -Znext-solver=globally, this could panic while reporting an error, avoiding the panic. Make proof tree replay fallible in diagnostics and fall back to the current obligation when replay fails. Add a regression test for the higher-ranked PartialEq and PartialOrd case. Fixes rust-lang/rust#151304.
Ensure inferred let pattern types are well-formed same as rust-lang/rust#157013 but with crater and fpc r? lcnr
…nthey Implement `to_string()` on `ByteStr` and `ByteString`
Add regression test for assoc const panic ICE in match Closes rust-lang/rust#91514, The associated const panic!() in a match used to ICE and now fails const eval cleanly
Rename `HostEffectPredicate` to `HostEffectClause` Part of rust-lang/rust#107250 r? oli-obk
Optimize new solver unification table ops The current code uses the `ena` crate in sub-optimal ways. Improving this gives big speed wins for the new trait solver on some benchmarks. Details in individual commits. r? @lcnr
…uwer Rollup of 7 pull requests Successful merges: - rust-lang/rust#160629 ([Priroda] Add bootstrap test and check steps) - rust-lang/rust#160811 (Fix `visible_parent_map` fallback map merging perf regression) - rust-lang/rust#154329 (Diagnostics ICE when replaying proof trees with next-solver) - rust-lang/rust#157841 (Ensure inferred let pattern types are well-formed) - rust-lang/rust#159300 (Implement `to_string()` on `ByteStr` and `ByteString`) - rust-lang/rust#160858 (Add regression test for assoc const panic ICE in match) - rust-lang/rust#160864 (Rename `HostEffectPredicate` to `HostEffectClause`)
Add back homu-ignore markers around the PR template Besides reinstantiating the `homu-ignore` markers from rust-lang/rust#126501, this PR also adds better clarification how the homu-ignore markers actually work; I've then also moved that section further down as it seems less important than the other parts of the PR template message. (We shouldn't forget that this is a *general PR template message*, not a LLM-policy-specific message.) The disclosure markers appear to have been accidentally removed together with the checkboxes in rust-lang/rust#160785. In the future, if support for ignoring HTML comments in places such as markdown code blocks was added, the new description about how `<!-- homu-ignore:end -->`/`<!-- homu-ignore:start -->` can be used could be further simplified[^1], but I'd like to address the immediate issues first before considering any more involved improvements (there already *exist* [currently ~~6~~ 8] new PRs now that contain the whole template comment without `homu-ignore` markers). [^1]: actually it may always stay non-ideal given that HTML comments don't nest 🫠
core: generalize `BorrowedCursor::ensure_init` Tracking issue: rust-lang/rust#160476 This implements the future possibility left out in rust-lang/rust#149749 (comment) and makes `ensure_init` generic over `Default`. I used specialisation to make sure the performance in the `u8` case stays equivalent to `memset` irrespective of how clever the optimiser happens to be. CC @joshtriplett as you've been working on this stuff recently. This also adds a public `write_default` method on `[MaybeUninit<T>]` that's doing the equivalent of `.write_init(|_| Default::default())`, but uses specialisation for integers. This uses the existing [tracking issue for `maybe_uninit_fill`](rust-lang/rust#117428).
use `static` instead of `const` for derive(Debug) r? @ghost
Update books ## rust-lang/reference 9 commits in afdc77bab886d4455c11247cdd32391bfab636ae..82da570bafd9efed421bdbae0f8603ede8dd308b 2026-08-08 22:04:17 UTC to 2026-07-28 18:20:15 UTC - add c-variadic function definitions (rust-lang/reference#2177) - Update `no_mangle` to use the attribute template (rust-lang/reference#1904) - enums with fields: clarify that repr(C, int) is quite different from repr(int) (rust-lang/reference#2227) - aliasing rules also apply inside private fields (rust-lang/reference#2304) - attributes: do not explain syntax in rules (rust-lang/reference#2306) - Document prohibition on inner attribute macros (rust-lang/reference#2311) - Use authentication for linkcheck (rust-lang/reference#2319) - Stabilize passing 128-bit integers via vector registers with `asm!` on x86 (rust-lang/reference#2313) - Add a rule for attribute macro outline modules (rust-lang/reference#2310)
Implement <OnceCell,OnceLock>::new_init Tracking issues: rust-lang/rust#159859 rust-lang/rust#159860 I'm not sure If I was supposed to add any other tests apart from the doc tests.
Rollup of 6 pull requests Successful merges: - rust-lang/rust#160872 (Add back homu-ignore markers around the PR template) - rust-lang/rust#160432 (core: generalize `BorrowedCursor::ensure_init`) - rust-lang/rust#160843 (Overhaul `rustc_query_impl`) - rust-lang/rust#160865 (use `static` instead of `const` for derive(Debug)) - rust-lang/rust#160866 (Update books) - rust-lang/rust#160881 (Implement <OnceCell,OnceLock>::new_init)
Switch try jobs to c8a.8xlarge This also expands the instance type list. Our current selection (12xlarge) is at best 2-3 minutes faster than 8xlarge based on rough benchmarks, which isn't worth the extra ~$0.72/build. See description of rust-lang/simpleinfra#1132 for those results. We expand the instance list to include even smaller instances because we might experiment with using those smaller instances for non-try jobs (e.g., auto and unrolled perf builds) because latency matters less there. That's not done in this commit though. Unfortunately I think we cannot easily test this before landing it, since AFAICT bors will read the configuration only once it's actually on main. rust-lang/bors-kindergarten#59 (once merged) should give us some test experience with this before we proceed with things in rust-lang/rust. r? Kobzol
Avoid allocations when canonicalizing Canonicalization is hot in the new solver. This commit avoids some allocations while doing it. Details in individual commits. r? @lcnr
Member
|
Odd, a genmc test and the 32bit native-lib tests are somehow constructing references with a bad size or so? |
Member
Author
|
Yeah. I'm stumped on this one because genmc doesn't build locally, and I'm not sure what to do with the 32-bit tests. If you have a fix for these problems feel free to merge it, I'll look into this more tomorrow. At a glance, I think it would be good to see in CI what address is being used that's no good in the 32-bit case. |
…white only next-solver: move implied bounds computation out of borrowck version of rust-lang/rust#160491 which does not enable this change for the old solver, meaning that we can merge it without a types team FCP :> r? adwinwhite
Member
|
I have 7h in a train this afternoon / evening, will do further investigation then. |
Member
|
Oh I think I got it 🤦 the logic I added in |
Bump the version number to 1.100.0 https://forge.rust-lang.org/release/process.html#bump-the-stable-version-number-friday-the-week-before r? me
fix buggy MaybeDangling<&T> validation logic Fixes a critical regression in rust-lang/rust#160749. This is what caused the trouble in rust-lang#5252. r? @oli-obk or @saethlin
…s, r=jackh726 Add regression test for #159890 Adds regression coverage for rust-lang/rust#159890 The ICE no longer reproduces after the canonical response universe assumptions fix landed. this keeps the original reproducer as a UI test and checks that it reports the expected E0195 and E0046 diagnostics instead of panicking Closes rust-lang/rust#159890
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Aug 15, 2026
…=saethlin fix buggy MaybeDangling<&T> validation logic Fixes a critical regression in rust-lang#160749. This is what caused the trouble in rust-lang/miri#5252. r? @oli-obk or @saethlin
…uwer Rollup of 2 pull requests Successful merges: - rust-lang/rust#161125 (fix buggy MaybeDangling<&T> validation logic) - rust-lang/rust#159971 (Add regression test for rust-lang/rust#159890)
rust-timer
added a commit
to rust-lang/rust
that referenced
this pull request
Aug 15, 2026
Rollup merge of #161125 - RalfJung:MaybeDangling-validity, r=saethlin fix buggy MaybeDangling<&T> validation logic Fixes a critical regression in #160749. This is what caused the trouble in rust-lang/miri#5252. r? @oli-obk or @saethlin
rust-bors Bot
pushed a commit
to rust-lang/rust
that referenced
this pull request
Aug 15, 2026
Rollup merge of #161125 - RalfJung:MaybeDangling-validity, r=saethlin fix buggy MaybeDangling<&T> validation logic Fixes a critical regression in #160749. This is what caused the trouble in rust-lang/miri#5252. r? @oli-obk or @saethlin
This updates the rust-version file to 67854e511de21d881bb16426996cd4259d44aa2e.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@67854e5 Filtered ref: rust-lang/miri@c0147d9 Upstream diff: rust-lang/rust@4667d75...67854e5 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
RalfJung
enabled auto-merge
August 16, 2026 08:32
RalfJung
force-pushed
the
rustup
branch
2 times, most recently
from
August 16, 2026 09:14
a3accf8 to
aae49bc
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.