2021 cargo fix --edition ICE: type parameter out of range when substituting
#90024
Comments
barakplasma
added
C-bug
|
cc @rust-lang/wg-rfc-2229 ICE in |
|
Here is a relatively smaller reproduction using the #![warn(rust_2021_incompatible_closure_captures)]
pub fn graph(activations: Vec<String>) -> im_rc::OrdMap<String, String> {
let mut graph = im_rc::OrdMap::new();
activations.iter().for_each(|r| {
graph.entry(r.clone()).or_insert_with(String::new);
});
graph
}It's a bit tricky to remove im_rc, as those types have a large number of recursive generic types (via typenum). |
|
I lost track of whether my reduction still compiled while reducing pub struct Graph<N, E, Ix> {
nodes: Vec<N>,
edges: Vec<E>,
ix: Vec<Ix>,
}
fn graph<N, E>() -> Graph<N, E, u32> {
todo!()
}
fn main() {
let g = graph();
|| g.hello()
}I'll see if I can reduce petgraph again, while keeping things compiling this time, so that using |
ehuss
changed the title
Ix/#3 (Ix/3) out of range when substituting, substs=[petgraph::graph::Edge<E, Ix>, std::alloc::Global]cargo fix --edition ICE: type parameter out of range when substituting
camelid
added
the
I-prioritize
|
It's very similar to the previous one, and the other reductions from similar issues: pub struct Graph<N, E, Ix> {
_edges: E,
_nodes: N,
_ix: Vec<Ix>,
}
fn graph<N, E>() -> Graph<N, E, i32> {
todo!()
}
fn main() {
let g = graph::<i32, i32>();
let _ = || g;
} |
camelid
added
the
regression-from-stable-to-stable
|
@arora-aman I had started looking into #90140 and was about to claim it before realizing this one had been claimed; apologies, did not mean to step on any toes. I have not written any code yet, so hopefully we shouldn't be doing duplicate work; I'll leave my results here and either you or I (or someone else) can implement a fix, however you like. I believe the issue is which incorrectly assumes the values returned from (self.adt_components)(adt_def, substs) still need a .subst() call. This assumption is indeed correct if that call returns the fields of the ADT (as it does if the ADT is !Drop) but wrong if the call returns the generic params of the ADT (as it does if it is insignificant Drop). That should be the cause of both this issue, #90140 , and #90169 .
|
|
Thank you for looking into this :) @JakobDegen that's about what I was thinking. I haven't written any code yet, so if you have time please go ahead and implement the fix, sooner this gets fixed the better! |
Uses 2 MCVEs from the issue tracker that test opposite sides of the problem.
|
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group. @rustbot label -I-prioritize +P-high |
rustbot
added
P-high
|
@ehuss should this issue be un-pinned now that it's fixed? Or is it still pinned to track backporting? |
|
I think it will be fine to keep it up for a while, as it is still an issue on stable which is what I expect most people are using. |
Ah, I think I see: you have it pinned so people won't file duplicates. Makes sense 👍 |
See rust-lang#90024 (comment) (cherry picked from commit 9158fc2)
Uses 2 MCVEs from the issue tracker that test opposite sides of the problem. (cherry picked from commit eae42fd)
|
The current milestone under which this issue is listed is 1.56.0, but it only got fixed in #90218 for 1.57.0. Can the milestone of this issue be updated to 1.57.0? |
|
Generally we use the milestone in issues for when the regression appeared (or more like "which release should we consider this for"). The PRs that resolve an issue get tagged with the release where the issue actually gets fixed (not including backports). Usually we don't retroactively change the milestone for closed issues. I'm going to unpin this issue as I think it has been up for sufficiently long. |
Encountered while running
RUST_BACKTRACE=1 cargo +nightly fix --editionfor frawk (on this specific/latest commit): https://github.com/ezrosent/frawk/tree/401fc14498c72187037a7e42fc3f2b607137ec0aCode
Since this happened in a dependency of the project I'm building, I am not sure which line of code led to this issue.
Meta
Happens on +nightly or without +nightly
rustc +nightly --version --verbose:Error output
Backtrace
The text was updated successfully, but these errors were encountered: