Change:
<ins> // build-pass // This used to fail MIR validation due to the types on both sides of // an assignment not being equal. // The failure doesn't occur with a check-only build. fn iter_slice<'a, T>(xs: &'a [T]) -> impl Iterator<Item = &'a T> { xs.iter() } fn main() { iter_slice::<()> as fn(_) -> _; } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I created an empty hello world project with Cargo, the "gluon" library to it, then tried to compile. I understand this is something more than just an incompatibility between the nightly compiler and the library. Does not occur on stable. There's no code, I to of an empty project. : </details
It looks like the bound regions are preventing us from normalizing an opaque type, leading us to conclude that the LHS and RHS types are not actually equal.
cc
Well I thought our subtyping check would catch such things? Cc It would be great to get a minimal testcase out of this.
I thought something like this could be used to reproduce the problem, but so far I could not get it to ICE:
You're missing the from the original. Here's a short repro: <hr/For the record, the thing of note about is that it (, even, presumably accounting for the two errors), the function (which ) The function is 's , with the signature:
Nice, a repro! So return-position impl-trait is crucial here. (We don't really need a bisect as we know that this got introduced by checking that MIR assignments are properly typed, so removing that label as well.) Any proposal for how this could be handled? I don't even understand why it doesn't work, I thought we are deleting all the lifetimes, but clearly not enough of them.^^ Would moving back to a "type fold" (instead of this relator thing we are currently doing) help?
Marked this as p-critical as per the
I'm afraid I have no idea how to fix this. I tried using a , to no avail. I also tried switching the validation type comparison back to a , but that did not help either. The only thing I can offer is disabling the sanity check for assignments entirely. I wonder if the check that has in the cranelift backend can handle this case.
I thought that code was already getting a passed into it
Is the problem really due to alone, or do the late-bound lifetimes cause it?

Because the ICE message kind of looks like they are the thing that causes issues:
Late-bound lifetimes work elsewhere though and the is needed to reproduce the problem.
Are you normalizing? The aspect is not going to be used unless you actually normalize. You might need to do the hacky excessive erasure of lifetimes before even attempting to normalize as the bound lifetimes may block normalization. (so the bottom-up folder could erase lifetimes then normalize, at every single step)
It does handle this. I just tried to compile the repro with cgclif. Compilation fails on the same as without cgclif, but not before cg_clif successfully finished codegen.
What was the link to that check again?
calling with a reveal-all doesn't help. :/
hm, interesting. That looks like it would bail if the types are inside a struct, tuple or array though?
found a fix, I coded it up:
for the record, I specifically meant after removing all the bound lifetimes. miri already normalizes, so it would have to be stronger than that. (EDIT: appears to do what I was suggesting, although it shouldn't be necessary, see below) <hr/However, I believe I may have found the bug, and it's actually in normalization itself: That condition shouldn't be there - IIRC I copied it from the arm. While for associated type projections it makes sense, due to having to look up the (which may have different results depending on how the lifetimes are bound, or be unsound, I guess), it does not for , which behaves more like a type alias, and which should be completely sound to normalize under a binder. cc
the old code doesn't normalize, so I don't see how changes to normalization could help. Also I don't know any of that code so it likely makes more sense for someone else to take over then.
This regressed in which is a rollup, I guess due to
This regressed in I removed the label because we knew that, but it's not helpful -- we don't want to just revert that PR as that would mean not checking MIR assignments any more.
right, I was going over the prioritization process and noticed that the PR where this regressed was lacking. I wasn't suggesting more than just that :).
Reopening as the problem remains on beta. can you do a backport?

is already , still this can be left open until we do the actual backport.
Oh I thought the beta PR would get nominated? Clearly I do not know the process. Feel free to close again if that's the process. :)
Hm, when you say "beta PR" -- is there a dedicated PR intended for beta backport? Or is slated for beta backport? Whichever PR's commits should be cherry-picked onto beta should get nominated.
Oh gosh now I confused everyone.^^ What I thought would happen is that someone cherry-picks onto the beta branch, opens that PR, and then marks it as nominated for the team to discuss. But best to ignore me as I clearly have no idea how you are doing backports.^^
the way it works is ... a PR that was made against master is labelled with requesting a backport for beta or requesting a backport for stable. During the following compiler weekly meeting members vote if the request should be accepted or rejected. If it is accepted a label or is and at that point ports that PR to the corresponding beta/stable branch. If it request is declined the or label is removed leaving the backport without effect.
We experienced a minor regression with the fix in PR , but there are known workarounds. The fix caused new "reached the type-length limit" compiler errors in our project. In our particular case, we didn't need the tracing::instrument spans that were creating the large types, so we deleted them (see ). This is a known issue in tracing - they increase the type-length limit as a workaround. It's also a known issue in rustc (). I the bisect-rustc regression report to that issue as
The fix seems to have been backported to beta. Can we close this?
What's the link to the beta PR? Yes I think it can be closed then.