-
-
Notifications
You must be signed in to change notification settings - Fork 15k
rustc doesn't compile with the new solver #158037
Copy link
Copy link
Closed
Labels
C-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.WG-trait-system-refactorThe Rustc Trait System Refactor Initiative (-Znext-solver)The Rustc Trait System Refactor Initiative (-Znext-solver)
Description
Metadata
Metadata
Assignees
Labels
C-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.WG-trait-system-refactorThe Rustc Trait System Refactor Initiative (-Znext-solver)The Rustc Trait System Refactor Initiative (-Znext-solver)
Type
Fields
Give feedbackNo fields configured for issues without a type.
To quote @lqd in #156141 (comment):
While trying to expand new solver testing in CI to keep it working, I've noticed that not only had we regressed building the stdlib (we knew that and now have CI to prevent that from happening before stabilization), we also regressed bootstrapping with the new solver enabled. That issue is still present on the main branch.
Building a stage 2 compiler with a stage 1 w/ new solver compiler, or RUSTFLAGS, will ICE very strangely while building
regex_syntax(and I can't easily reproduce building that crate by itself...):(e.g. with
RUSTFLAGS_NOT_BOOTSTRAP="-Znext-solver=globally" ./x build library --stage 2. Fun: I can reproduce the ICE locally on different machines, but not on CI. what.)I don't really know what's going on, but it looks like weirdness w/ opaque types, during codegen. I've bisected that to 68f9143 from this PR so I wanted to let you and @lcnr know in case you hadn't noticed.
@rustbot claim