regression: failed to normalize alias(opaque ...) #123276
Labels
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
P-medium
Medium priority
S-has-mcve
Status: A Minimal Complete and Verifiable Example has been found for this issue
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Milestone
Comments
Mark-Simulacrum
added
I-ICE
rustbot
added
I-prioritize
Closed
|
Trying to bisect. Not so easy because cargo-bisect runs on nightlies and on nightly this crate does not compile. WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-medium |
rustbot
added
P-medium
jieyouxu
added
E-needs-bisection
|
Using a patched version of searched nightlies: from nightly-2024-02-01 to nightly-2024-03-17 bisected with cargo-bisect-rustc v0.6.8Host triple: aarch64-apple-darwin cargo bisect-rustc --regress=ice --start=2024-02-01 --end=2024-03-17 @rustbot label: -E-needs-bisection |
rustbot
removed
the
E-needs-bisection
|
Yea, this crate already errors with before it ICEs, so while this is an ICE to be fixed, it's not beta critical |
oli-obk
removed
regression-from-stable-to-beta
💀 nightly feature detection is starting to affect rustc development |
|
Minimized: async fn create_task() {
_ = Some(async { bind(documentation_filter()) });
}
async fn bind<Fut, F: Filter<Future = Fut>>(_: F) {}
fn documentation_filter() -> impl Filter {
AndThen
}
trait Filter {
type Future;
}
struct AndThen;
impl Filter for AndThen
where
Foo: Filter,
{
type Future = ();
}Produces@rustbot label: -E-needs-mcve +S-has-mcve |
rustbot
added
S-has-mcve
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this issue
Jun 19, 2024
Actually taint InferCtxt when a fulfillment error is emitted And avoid checking the global error counter fixes rust-lang#122044 fixes rust-lang#123255 fixes rust-lang#123276 fixes rust-lang#125799
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this issue
Jun 19, 2024
Actually taint InferCtxt when a fulfillment error is emitted And avoid checking the global error counter fixes rust-lang#122044 fixes rust-lang#123255 fixes rust-lang#123276 fixes rust-lang#125799
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this issue
Jun 19, 2024
Actually taint InferCtxt when a fulfillment error is emitted And avoid checking the global error counter fixes rust-lang#122044 fixes rust-lang#123255 fixes rust-lang#123276 fixes rust-lang#125799
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 20, 2024
Rollup merge of rust-lang#126620 - oli-obk:taint_errors, r=fee1-dead Actually taint InferCtxt when a fulfillment error is emitted And avoid checking the global error counter fixes rust-lang#122044 fixes rust-lang#123255 fixes rust-lang#123276 fixes rust-lang#125799
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Jul 9, 2024
…wiser allow overwriting the output of `rustc --version` Our wonderful bisection folk [have to work around](rust-lang#123276 (comment)) crates that do incomplete nightly/feature detection, as otherwise the bisection just points to where the feature detection breaks, and not to the actual breakage they are looking for. This is also annoying behaviour to nightly users who did not opt-in to those nightly features. Most nightly users want to be in control of the nightly breakage they get, by * choosing when to update rustc * choosing when to update dependencies * choosing which nightly features they are willing to take the breakage for The reason this breakage occurs is that the build script of some crates run `rustc --version`, and if the version looks like nightly or dev, it will enable nightly features. These nightly features may break in random ways whenever we change something in nightly, so every release of such a crate will only work with a small range of nightly releases. This causes bisection to fail whenever it tries an unsupported nightly, even though that crate is not related to the bisection at all, but is just an unrelated dependency. This PR (and the policy I want to establish with this FCP) is only for situations like the `version_check`'s `supports_feature` function. It is explicitly not for `autocfg` or similar feature-detection-by-building-rust-code, irrespective of my opinions on it and the similarity of nightly breakage that can occur with such schemes. These cause much less breakage, but should the breakage become an issue, they should get covered by this policy, too. This PR allows changing the version and release strings reported by `rustc --version` via the `RUSTC_FORCE_RUSTC_VERSION` env var. The bisection issue is then fixed by rust-lang/cargo-bisect-rustc#335. I mainly want to establish a compiler team policy: > We do not consider feature detection on nightly (on stable via compiler version numbering is fine) a valid use case that we need to support, and if it causes problems, we are at liberty to do what we deem best - either actively working to prevent it or to actively ignore it. We may try to work with responsive and cooperative authors, but are not obligated to. Should they subvert the workarounds that nightly users or cargo-bisect-rustc can use, we should be able to land rustc PRs that target the specific crates that cause issues for us and outright replace their build script's logic to disable nightly detection. I am not including links to crates, PRs or issues here, as I don't actually care about the specific use cases and don't want to make it trivial to go there and leave comments. This discussion is going to be interesting enough on its own, without branching out.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Jul 26, 2024
…wiser allow overwriting the output of `rustc --version` Our wonderful bisection folk [have to work around](rust-lang#123276 (comment)) crates that do incomplete nightly/feature detection, as otherwise the bisection just points to where the feature detection breaks, and not to the actual breakage they are looking for. This is also annoying behaviour to nightly users who did not opt-in to those nightly features. Most nightly users want to be in control of the nightly breakage they get, by * choosing when to update rustc * choosing when to update dependencies * choosing which nightly features they are willing to take the breakage for The reason this breakage occurs is that the build script of some crates run `rustc --version`, and if the version looks like nightly or dev, it will enable nightly features. These nightly features may break in random ways whenever we change something in nightly, so every release of such a crate will only work with a small range of nightly releases. This causes bisection to fail whenever it tries an unsupported nightly, even though that crate is not related to the bisection at all, but is just an unrelated dependency. This PR (and the policy I want to establish with this FCP) is only for situations like the `version_check`'s `supports_feature` function. It is explicitly not for `autocfg` or similar feature-detection-by-building-rust-code, irrespective of my opinions on it and the similarity of nightly breakage that can occur with such schemes. These cause much less breakage, but should the breakage become an issue, they should get covered by this policy, too. This PR allows changing the version and release strings reported by `rustc --version` via the `RUSTC_OVERRIDE_VERSION_STRING` env var. The bisection issue is then fixed by rust-lang/cargo-bisect-rustc#335. I mainly want to establish a compiler team policy: > We do not consider feature detection on nightly (on stable via compiler version numbering is fine) a valid use case that we need to support, and if it causes problems, we are at liberty to do what we deem best - either actively working to prevent it or to actively ignore it. We may try to work with responsive and cooperative authors, but are not obligated to. Should they subvert the workarounds that nightly users or cargo-bisect-rustc can use, we should be able to land rustc PRs that target the specific crates that cause issues for us and outright replace their build script's logic to disable nightly detection. I am not including links to crates, PRs or issues here, as I don't actually care about the specific use cases and don't want to make it trivial to go there and leave comments. This discussion is going to be interesting enough on its own, without branching out.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jul 29, 2024
allow overwriting the output of `rustc --version` Our wonderful bisection folk [have to work around](rust-lang#123276 (comment)) crates that do incomplete nightly/feature detection, as otherwise the bisection just points to where the feature detection breaks, and not to the actual breakage they are looking for. This is also annoying behaviour to nightly users who did not opt-in to those nightly features. Most nightly users want to be in control of the nightly breakage they get, by * choosing when to update rustc * choosing when to update dependencies * choosing which nightly features they are willing to take the breakage for The reason this breakage occurs is that the build script of some crates run `rustc --version`, and if the version looks like nightly or dev, it will enable nightly features. These nightly features may break in random ways whenever we change something in nightly, so every release of such a crate will only work with a small range of nightly releases. This causes bisection to fail whenever it tries an unsupported nightly, even though that crate is not related to the bisection at all, but is just an unrelated dependency. This PR (and the policy I want to establish with this FCP) is only for situations like the `version_check`'s `supports_feature` function. It is explicitly not for `autocfg` or similar feature-detection-by-building-rust-code, irrespective of my opinions on it and the similarity of nightly breakage that can occur with such schemes. These cause much less breakage, but should the breakage become an issue, they should get covered by this policy, too. This PR allows changing the version and release strings reported by `rustc --version` via the `RUSTC_OVERRIDE_VERSION_STRING` env var. The bisection issue is then fixed by rust-lang/cargo-bisect-rustc#335. I mainly want to establish a compiler team policy: > We do not consider feature detection on nightly (on stable via compiler version numbering is fine) a valid use case that we need to support, and if it causes problems, we are at liberty to do what we deem best - either actively working to prevent it or to actively ignore it. We may try to work with responsive and cooperative authors, but are not obligated to. Should they subvert the workarounds that nightly users or cargo-bisect-rustc can use, we should be able to land rustc PRs that target the specific crates that cause issues for us and outright replace their build script's logic to disable nightly detection. I am not including links to crates, PRs or issues here, as I don't actually care about the specific use cases and don't want to make it trivial to go there and leave comments. This discussion is going to be interesting enough on its own, without branching out.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jul 30, 2024
allow overwriting the output of `rustc --version` Our wonderful bisection folk [have to work around](rust-lang#123276 (comment)) crates that do incomplete nightly/feature detection, as otherwise the bisection just points to where the feature detection breaks, and not to the actual breakage they are looking for. This is also annoying behaviour to nightly users who did not opt-in to those nightly features. Most nightly users want to be in control of the nightly breakage they get, by * choosing when to update rustc * choosing when to update dependencies * choosing which nightly features they are willing to take the breakage for The reason this breakage occurs is that the build script of some crates run `rustc --version`, and if the version looks like nightly or dev, it will enable nightly features. These nightly features may break in random ways whenever we change something in nightly, so every release of such a crate will only work with a small range of nightly releases. This causes bisection to fail whenever it tries an unsupported nightly, even though that crate is not related to the bisection at all, but is just an unrelated dependency. This PR (and the policy I want to establish with this FCP) is only for situations like the `version_check`'s `supports_feature` function. It is explicitly not for `autocfg` or similar feature-detection-by-building-rust-code, irrespective of my opinions on it and the similarity of nightly breakage that can occur with such schemes. These cause much less breakage, but should the breakage become an issue, they should get covered by this policy, too. This PR allows changing the version and release strings reported by `rustc --version` via the `RUSTC_OVERRIDE_VERSION_STRING` env var. The bisection issue is then fixed by rust-lang/cargo-bisect-rustc#335. I mainly want to establish a compiler team policy: > We do not consider feature detection on nightly (on stable via compiler version numbering is fine) a valid use case that we need to support, and if it causes problems, we are at liberty to do what we deem best - either actively working to prevent it or to actively ignore it. We may try to work with responsive and cooperative authors, but are not obligated to. Should they subvert the workarounds that nightly users or cargo-bisect-rustc can use, we should be able to land rustc PRs that target the specific crates that cause issues for us and outright replace their build script's logic to disable nightly detection. I am not including links to crates, PRs or issues here, as I don't actually care about the specific use cases and don't want to make it trivial to go there and leave comments. This discussion is going to be interesting enough on its own, without branching out.
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Aug 2, 2024
allow overwriting the output of `rustc --version` Our wonderful bisection folk [have to work around](rust-lang/rust#123276 (comment)) crates that do incomplete nightly/feature detection, as otherwise the bisection just points to where the feature detection breaks, and not to the actual breakage they are looking for. This is also annoying behaviour to nightly users who did not opt-in to those nightly features. Most nightly users want to be in control of the nightly breakage they get, by * choosing when to update rustc * choosing when to update dependencies * choosing which nightly features they are willing to take the breakage for The reason this breakage occurs is that the build script of some crates run `rustc --version`, and if the version looks like nightly or dev, it will enable nightly features. These nightly features may break in random ways whenever we change something in nightly, so every release of such a crate will only work with a small range of nightly releases. This causes bisection to fail whenever it tries an unsupported nightly, even though that crate is not related to the bisection at all, but is just an unrelated dependency. This PR (and the policy I want to establish with this FCP) is only for situations like the `version_check`'s `supports_feature` function. It is explicitly not for `autocfg` or similar feature-detection-by-building-rust-code, irrespective of my opinions on it and the similarity of nightly breakage that can occur with such schemes. These cause much less breakage, but should the breakage become an issue, they should get covered by this policy, too. This PR allows changing the version and release strings reported by `rustc --version` via the `RUSTC_OVERRIDE_VERSION_STRING` env var. The bisection issue is then fixed by rust-lang/cargo-bisect-rustc#335. I mainly want to establish a compiler team policy: > We do not consider feature detection on nightly (on stable via compiler version numbering is fine) a valid use case that we need to support, and if it causes problems, we are at liberty to do what we deem best - either actively working to prevent it or to actively ignore it. We may try to work with responsive and cooperative authors, but are not obligated to. Should they subvert the workarounds that nightly users or cargo-bisect-rustc can use, we should be able to land rustc PRs that target the specific crates that cause issues for us and outright replace their build script's logic to disable nightly detection. I am not including links to crates, PRs or issues here, as I don't actually care about the specific use cases and don't want to make it trivial to go there and leave comments. This discussion is going to be interesting enough on its own, without branching out.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: