-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICE on rustc 1.26.0-nightly (ae544ee1c 2018-03-29) #49534
Comments
Can you try a few older nightlies to determine which day has this regressed? Looks similar to #46197, so maybe you can check that thread as well. |
From #50668: this has also regressed stable. |
@topecongiro perhaps you can https://github.com/rust-lang-nursery/cargo-bisect-rustc to nail down more precisely what led to the problem? if so, that would be 💯! |
I'll assign to myself but mostly trying to veirfy if this is indeed a dup of #46197 to start |
I wonder if this is something a beginner can solve, since this looks like a regression? If so, I can take a look? |
@Swoorup #49534 (comment) has some instructions for what you can start with, but actually fixing the root cause may be hard. Either way, if you report back the team members will answer your questions. |
Note that #46197 -- of which this is possibly a dup -- was itself a dup of another issue, which has been fixed. So it's possible that there is no bug here (but in that case, the original source should now fail to compile with a compilation error). Can anyone verify that? (cc @topecongiro) |
looking at it |
it successfully compiles by rustc 1.28.0-nightly (2a00629 2018-06-09), of cause after several fixes not related to the ICE commit. |
@mikhail-m1 to be clear, you mean that the specific commit of rustfmt is working now? In other words, the ICE is gone? In that case, we can probably close, even if we don't know the exact cause. |
yes, it works, I think it's enough for close |
Still crashing using this code on playground on nightly |
thanks for nice sample, stack backtrace is same, I will look at it, minimized:
|
This might be fixed by #51686 |
Yes, it is. |
…t-bindings-bug, r=eddyb yet another "old borrowck" bug around match default bindings We were getting the type of the parameter from its pattern, but that didn't include adjustments. I did a `ripgrep` around and this seemed to be the only affected case. The reason this didn't show up as an ICE earlier is that mem-categorization is lenient with respect to weird discrepancies. I am going to add more delay-span-bug calls shortly around that (I'll push onto the PR). This example is an ICE, but I presume that there is a way to make a soundness example out of this -- it basically ignores borrows occuring inside match-default-bindings in a closure, though only if the implicit deref is at the top-level. It happens though that this occurs frequently in iterators, which often give a `&T` parameter. Fixes #51415 Fixes #49534 r? @eddyb
I encountered an ICE while working on rustfmt (my branch) with this commit. I am using
1.26.0-nightly (ae544ee1c 2018-03-29)
.Log
Backtrace
The text was updated successfully, but these errors were encountered: