stepping into where-clauses during normalization may be productive#155388
Open
lcnr wants to merge 1 commit into
Open
stepping into where-clauses during normalization may be productive#155388lcnr wants to merge 1 commit into
lcnr wants to merge 1 commit into
Conversation
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
lcnr
force-pushed
the
norm-where-bounds-may-be-productive
branch
from
April 17, 2026 07:58
7e15d0a to
7149592
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
lcnr
force-pushed
the
norm-where-bounds-may-be-productive
branch
from
April 17, 2026 09:33
7149592 to
45934b8
Compare
Member
|
@rustbot author pending figuring out how breaking this is |
rustbot
removed
the
S-waiting-on-review
Collaborator
|
Reminder, once the PR becomes ready for a review, use |
rustbot
added
the
S-waiting-on-author
This comment has been minimized.
This comment has been minimized.
Contributor
|
Not sure if you're already aware but this PR ICEs on the following //@ revisions: current next
//@ ignore-compare-mode-next-solver (explicit revisions)
//@[next] compile-flags: -Znext-solver
//@ edition: 2021
//@ compile-flags: --crate-type=lib
//@ build-pass
use std::future::Future;
use std::pin::Pin;
use std::sync::Arc;
use std::task::Context;
use std::task::Poll;
struct Buffer;
type Result<T> = std::result::Result<T, ()>;
type BoxedFuture<'a, T> = Pin<Box<dyn Future<Output = T> + Send + 'a>>;
trait Read: Unpin + Send {
fn read(&mut self) -> impl Future<Output = Result<Buffer>>;
}
trait ReadDyn: Unpin + Send + Sync {}
type Reader = Box<dyn ReadDyn>;
trait Access: Send + Sync + Unpin {
type Reader;
fn read(&self) -> impl Future<Output = Result<(u32, Self::Reader)>> + Send;
}
trait AccessDyn: Send + Sync + Unpin {
fn read_dyn(&self) -> BoxedFuture<'_, Result<(u32, Reader)>>;
}
impl Access for dyn AccessDyn {
type Reader = Reader;
async fn read(&self) -> Result<(u32, Self::Reader)> {
self.read_dyn().await
}
}
impl<T: Access + ?Sized> Access for Arc<T> {
type Reader = T::Reader;
fn read(&self) -> impl Future<Output = Result<(u32, Self::Reader)>> + Send {
async { self.as_ref().read().await }
}
}
struct ReadContext {
acc: Arc<dyn AccessDyn>,
}
struct ReadGenerator {
ctx: Arc<ReadContext>,
}
impl ReadGenerator {
async fn next_reader(&self) -> Result<Option<Reader>> {
let (_, r) = self.ctx.acc.read().await?;
Ok(Some(r))
}
}
trait Stream {
type Item;
fn poll_next(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Option<Self::Item>>;
}
enum TwoWays<A, B> {
One(A),
Two(B),
}
impl<A: Read, B: Read> Read for TwoWays<A, B> {
async fn read(&mut self) -> Result<Buffer> {
match self {
TwoWays::One(v) => v.read().await,
TwoWays::Two(v) => v.read().await,
}
}
}
struct StreamingReader {
generator: ReadGenerator,
}
impl Read for StreamingReader {
async fn read(&mut self) -> Result<Buffer> {
let _ = self.generator.next_reader().await;
loop {}
}
}
struct ChunkedReader;
impl Read for ChunkedReader {
async fn read(&mut self) -> Result<Buffer> {
loop {}
}
}
enum State {
Idle(Option<TwoWays<StreamingReader, ChunkedReader>>),
Reading(Pin<Box<dyn Future<Output = (TwoWays<StreamingReader, ChunkedReader>, Result<Buffer>)> + Send>>),
}
struct BufferStream {
state: State,
}
impl Stream for BufferStream {
type Item = Result<()>;
fn poll_next(self: Pin<&mut Self>, _cx: &mut Context<'_>) -> Poll<Option<Self::Item>> {
let this = unsafe { self.get_unchecked_mut() };
loop {
match &mut this.state {
State::Idle(reader) => {
let mut reader = reader.take().unwrap();
let fut = async {
let ret = reader.read().await;
(reader, ret)
};
this.state = State::Reading(Box::pin(fut));
}
State::Reading(_) => return Poll::Pending,
}
}
}
}with while current main doesn't. |
Contributor
|
Hm never mind looks like it passes after rebase on main |
lcnr
force-pushed
the
norm-where-bounds-may-be-productive
branch
from
July 16, 2026 07:46
45934b8 to
20b2ce1
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
lcnr
force-pushed
the
norm-where-bounds-may-be-productive
branch
from
July 16, 2026 09:10
20b2ce1 to
e4c693d
Compare
lcnr
changed the title
NormalizesTo where-clauses may be productive
Member
lcnr
force-pushed
the
norm-where-bounds-may-be-productive
branch
from
July 22, 2026 11:02
e4c693d to
66d0fb8
Compare
Collaborator
|
This PR was rebased onto a different main 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. |
Contributor
Author
|
@bors r=BoxyUwU rollup (next-solver only) |
Member
|
@bors treeclosed=1 spurious CI failures |
Contributor
|
Tree closed for PRs with priority less than 1. |
Member
|
@bors retry |
rust-bors
Bot
added
S-waiting-on-bors
This was referenced Jul 24, 2026
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
This was referenced Jul 24, 2026
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jul 24, 2026
…uctive, r=BoxyUwU stepping into where-clauses during normalization may be productive fixes rust-lang/trait-system-refactor-initiative#273, see that issue for more info. Whether stepping into a where-clause is productive depends not on whether we're proving a `NormalizesTo` or `Trait` goal, but instead on how both the impl and the cycle rely on it. In the example in tests/ui/traits/next-solver/cycles/normalizes-to-is-not-productive-2.rs this is just a productive use given the way @Nadrieril and I are thinking about it right now. We're changing such cycles to be ambiguous for now, so this does not commit us to anything. This previously caused a lot of breakage when normalizing where-clauses, e.g. rust-lang/trait-system-refactor-initiative#176, however with rust-lang#158643 that is no longer an issue. We will need to figure out what to do here if we want to properly fix `ParamEnv` normalization in the future r? @BoxyUwU or @nikomatsakis
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jul 24, 2026
…uctive, r=BoxyUwU stepping into where-clauses during normalization may be productive fixes rust-lang/trait-system-refactor-initiative#273, see that issue for more info. Whether stepping into a where-clause is productive depends not on whether we're proving a `NormalizesTo` or `Trait` goal, but instead on how both the impl and the cycle rely on it. In the example in tests/ui/traits/next-solver/cycles/normalizes-to-is-not-productive-2.rs this is just a productive use given the way @Nadrieril and I are thinking about it right now. We're changing such cycles to be ambiguous for now, so this does not commit us to anything. This previously caused a lot of breakage when normalizing where-clauses, e.g. rust-lang/trait-system-refactor-initiative#176, however with rust-lang#158643 that is no longer an issue. We will need to figure out what to do here if we want to properly fix `ParamEnv` normalization in the future r? @BoxyUwU or @nikomatsakis
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 24, 2026
Rollup of 17 pull requests Successful merges: - #158168 (Added implementation on `set_permissions_nofollow` for all primary platforms) - #138618 (Support using const pointers in asm `const` operand) - #157962 (Function item should not be used as const arg) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159411 ([rustdoc] Correctly handle output options with --show-coverage) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159809 (Avoid `#[target_features]`) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate)
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jul 25, 2026
…uctive, r=BoxyUwU stepping into where-clauses during normalization may be productive fixes rust-lang/trait-system-refactor-initiative#273, see that issue for more info. Whether stepping into a where-clause is productive depends not on whether we're proving a `NormalizesTo` or `Trait` goal, but instead on how both the impl and the cycle rely on it. In the example in tests/ui/traits/next-solver/cycles/normalizes-to-is-not-productive-2.rs this is just a productive use given the way @Nadrieril and I are thinking about it right now. We're changing such cycles to be ambiguous for now, so this does not commit us to anything. This previously caused a lot of breakage when normalizing where-clauses, e.g. rust-lang/trait-system-refactor-initiative#176, however with rust-lang#158643 that is no longer an issue. We will need to figure out what to do here if we want to properly fix `ParamEnv` normalization in the future r? @BoxyUwU or @nikomatsakis
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 25, 2026
Rollup of 16 pull requests Successful merges: - #138618 (Support using const pointers in asm `const` operand) - #157962 (Function item should not be used as const arg) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159411 ([rustdoc] Correctly handle output options with --show-coverage) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159809 (Avoid `#[target_features]`) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate)
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jul 25, 2026
…uctive, r=BoxyUwU stepping into where-clauses during normalization may be productive fixes rust-lang/trait-system-refactor-initiative#273, see that issue for more info. Whether stepping into a where-clause is productive depends not on whether we're proving a `NormalizesTo` or `Trait` goal, but instead on how both the impl and the cycle rely on it. In the example in tests/ui/traits/next-solver/cycles/normalizes-to-is-not-productive-2.rs this is just a productive use given the way @Nadrieril and I are thinking about it right now. We're changing such cycles to be ambiguous for now, so this does not commit us to anything. This previously caused a lot of breakage when normalizing where-clauses, e.g. rust-lang/trait-system-refactor-initiative#176, however with rust-lang#158643 that is no longer an issue. We will need to figure out what to do here if we want to properly fix `ParamEnv` normalization in the future r? @BoxyUwU or @nikomatsakis
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
6 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.
View all comments
fixes rust-lang/trait-system-refactor-initiative#273, see that issue for more info.
Whether stepping into a where-clause is productive depends not on whether we're proving a
NormalizesToorTraitgoal, but instead on how both the impl and the cycle rely on it.In the example in tests/ui/traits/next-solver/cycles/normalizes-to-is-not-productive-2.rs this is just a productive use given the way @Nadrieril and I are thinking about it right now.
We're changing such cycles to be ambiguous for now, so this does not commit us to anything.
This previously caused a lot of breakage when normalizing where-clauses, e.g. rust-lang/trait-system-refactor-initiative#176, however with #158643 that is no longer an issue. We will need to figure out what to do here if we want to properly fix
ParamEnvnormalization in the futurer? @BoxyUwU or @nikomatsakis