Rollup of 5 pull requests - #163437
Closed
JonathanBrouwer wants to merge 15 commits into
Closed
Rollup of 5 pull requests#163437JonathanBrouwer wants to merge 15 commits into
JonathanBrouwer wants to merge 15 commits into
Conversation
When it was added in PR 37412 it was a simple three-value lattice type implementing `PartialOrd`/`Ord`, and also implementing `BitAnd`/`BitOr` using `min`/`max`. This all made sense. Then in PR 64592 the `Always` variant got a span and a custom note added. This makes the meaning of all those operations much murkier. And the `is_always` method gained an alarming comment: > Enum comparison ignores the contents of fields, so we just fill them > in with garbage here. This is false! Enum comparison does use the contents of fields. This commit removes the `PartialOrd`/`Ord` impls and redoes `BitAnd`/`BitOr` in a way that preserves existing behaviour without relying on `span` and `custom_note` ordering. In the `Always`/`Always` case we now always use the fields from `self`; this is potentially different to the old behaviour but in practice no test outputs are affected, and at most some error messages might be slightly different. This helps with the next commit by removing some `Span` ordering operations.
The rustc driver sets the default stack size to 16MB, however worker threads spawned by the backend will use std's default stack size (usually 2MB). Pass through the stack size chosen by the driver to the backend, and explicitly request the stack size.
`Span` and `SpanData` encode four fields: `lo`/`hi`, `ctxt`, and `parent`. `ctxt` and `parent` have unorderable types. Both types ignore `ctxt` and `parent` for `PartialOrd`/`Ord`. But their `PartialEq`/`Eq` impls do *not* ignore those fields. This eq/ord inconsistency is a bug. It was introduced in rust-lang#123165. The idea of ordering spans in general is dubious, because of `ctxt` and `parent`. But the idea of ordering spans just with `lo`/`hi` is fine. Therefore, this commit does the following. - Removes the `PartialOrd`/`Ord` impls for `Span`/`SpanData` - Adds a `Span::lo_hi` method which can be used in lots of places where span locations are involved in sorting. E.g. `xs.sort_by_key(|span| span.lo_hi())` - Adds `OrdSpan`, a newtype around `Span` that impls `PartialEq`/`Eq`/`PartialOrd`/`Ord` using `lo_hi`. This is for storing spans in ordered types like `BTreeMap<OrdSpan, T>`. Note also that some `sort`+`dedup` combinations might not remove all duplicates with the old eq/ord inconsistency. These now all do the right thing, which could affect some error messages, though in practice nothing in the test suite is affected.
It can be replaced with `Span::lo_hi` + `==`.
… r=petrochenkov fix ice for unresolved inherent delegation fixes: [162774](rust-lang#162774) also adds a regression test for the ICE. plus follow-up commits addressing review feedback on error propagation for `TypeRelativeDelegationRes::Error`.
… r=jieyouxu x perf takes database path r? @jieyouxu (or anyone else who wants, it's not a very complicated change) > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
Yeet `propagate_ambiguity` Fixes rust-lang/project-assumptions-on-binders#29 When assumptions computation fails, we want to force the goal response to be ambiguous since we can't evaluate placeholder constraints. We used to do this via `LeafRegionConstraint::Ambiguity` and propagates it everywhere. This PR simplifies that by tracking whether we should force ambiguity in a more direct way. We just check whether we have computed assumptions for relevant universes. This also clarifies the meaning of `LeafRegionConstraint::Ambiguity` which only represents true ambiguity (forever ambiguity no matter inference progress). This doesn't solve the problem that we're being conservative about forcing ambiguity. Maybe we can have `false`s in some universes even if other universes don't have assumptions. We can be smart about this in the future. Unsure part: we can also have ambiguity from non-lifetime placeholder. Unsure what to do with that. Still trying to understand it. r? @BoxyUwU
Ensure llvm worker threads have sufficient stack space The rustc driver sets the default stack size to 16MB, however worker threads spawned by the backend will use std's default stack size (usually 2MB). Pass through the stack size chosen by the driver to the backend, and explicitly request the stack size. This probably isn't the preferred way to do this, but maybe a starting point to educate me. This doesn't catch every spawned thread (jobserver and ctrlc also create them through std). Are there other threads which might be sensitive to small stack sizes? Fixes rust-lang#163272
…-obk Remove `PartialOrd`/`Ord` impls for `Span`/`SpanData` Because they are inconsistent with the `PartialEq`/`Eq` impls, and span ordering is inherently dubious. Details in individual commits. r? @oli-obk
rustbot
added
A-attributes
Member
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 28, 2026
Rollup of 5 pull requests try-job: dist-various-1 try-job: test-various try-job: test-x86_64-gnu-aux try-job: test-x86_64-gnu-llvm-21-3 try-job: test-x86_64-msvc-1 try-job: test-aarch64-apple-1 try-job: test-aarch64-apple-2 try-job: test-x86_64-mingw-1 try-job: test-i686-msvc try-job: test-armhf-gnu
Contributor
|
⌛ Testing commit 629cec2 with merge 4014019... Workflow: https://github.com/rust-lang/rust/actions/runs/36420291458 |
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 28, 2026
…uwer Rollup of 5 pull requests Successful merges: - #162917 (fix ice for unresolved inherent delegation) - #163209 (x perf takes database path) - #162935 (Yeet `propagate_ambiguity`) - #163289 (Ensure llvm worker threads have sufficient stack space) - #163303 (Remove `PartialOrd`/`Ord` impls for `Span`/`SpanData`)
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
This pull request was unapproved due to being closed. Auto build was cancelled due to the PR being closed. Cancelled workflows: |
Contributor
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.
Successful merges:
propagate_ambiguity#162935 (Yeetpropagate_ambiguity)PartialOrd/Ordimpls forSpan/SpanData#163303 (RemovePartialOrd/Ordimpls forSpan/SpanData)r? @ghost
Create a similar rollup