-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Compiler panic on fairly simple match expression #51415
Comments
Here's a PR with the code that caused the crash: |
I compile frequently, and had made only a few changes between this and the last time I had compiled. I think the crash has something to do with the implementation of |
Can you provide a mcve? |
What's an "mcve"? |
Whoops, I thought that was an actual word, not an initialism. Giving it the 15 minute try... |
Well, I make no assertions about minimality, but this code snippet does fail on the rust playground w/ all six possible configurations and it's pretty short.
|
Smaller:
|
Smidge smaller:
|
ICE does not happen with |
You can make your example working by changing the |
Worked on 1.25.0 with an explicit error message.
|
I think might have been caused by the match ergonomics pr. |
Had a similar compiler panic with this snippet of code:
Changing it to the snippet below fixes the problem, so I definitely think the match ergonomics is doing something.
See it in the playground here. |
triage: P-high Hmm, this might be a problem with borrowck failing to catch a borrow (the NLL borrow checker seems to catch the error correctly). |
The problem seems to be specific to argument patterns. This code fails to compile as expected: fn main() {
let a = vec![String::from("a")];
let opt = a.iter().enumerate().find(|param| {
let (_, &s) = param; //~ ERROR
*s == String::from("d")
}).map(|(i, _)| i);
println!("{:?}", opt);
} |
…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
Here's the stack trace
The text was updated successfully, but these errors were encountered: