Skip to content
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

Incorrect matching on tuples with value ranges #12582

Closed
adwhit opened this issue Feb 27, 2014 · 0 comments · Fixed by #13034
Closed

Incorrect matching on tuples with value ranges #12582

adwhit opened this issue Feb 27, 2014 · 0 comments · Fixed by #13034

Comments

@adwhit
Copy link

adwhit commented Feb 27, 2014

If part of a tuple is already "mentioned" in a match (but the match misses because of the rest of the tuple), it then won't match on a later range either, regardless of whether it should.

Best demonstrated by example:

fn main() {
    let x = 1;
    let y = 2;

    let z = match (x,y) {
    (1,1) => 1,
    (2,2) => 2,
    (1..2,2) => 3,
    (_,_) => fail!("Shouldn't reach here but does")
    };
}
bors added a commit that referenced this issue Mar 27, 2014
The `_match.rs` takes advantage of passes prior to `trans` and
aggressively prunes the sub-match tree based on exact equality. When it
comes to literal or range, the strategy may lead to wrong result if
there's guard function or multiple patterns inside tuple.

Closes #12582.
Closes #13027.
@bors bors closed this as completed in 4112941 Mar 27, 2014
edwardw added a commit to edwardw/rust that referenced this issue May 5, 2014
By carefully distinguishing falling back to the default arm from moving
on to the next pattern, this patch adjusts the codegen logic for range
and guarded arms of pattern matching expression. It is a more
appropriate way of fixing rust-lang#12582 and rust-lang#13027 without causing regressions
such as rust-lang#13867.

Closes rust-lang#13867
bors added a commit that referenced this issue May 6, 2014
By carefully distinguishing falling back to the default arm from moving
on to the next pattern, this patch adjusts the codegen logic for range
and guarded arms of pattern matching expression. It is a more
appropriate way of fixing #12582 and #13027 without causing regressions
such as #13867.
    
Closes #13867
flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 4, 2024
`large_stack_frames`: print total size and largest component.

Instead of just saying “this function's stack frame is big”, report:

* the (presumed) size of the frame
* the size and type of the largest local contributing to that size
* the configurable limit that was exceeded (once)

Known issues:

* The lint may report an over-estimate because codegen may be able to overlap some of these locals. However, that already affected whether the lint fired at all; I believe this change is still an improvement because it gives the user much more actionable information about _why_ the lint fired.
* Please tell me a better way to determine whether a local has a variable name.

changelog: [`large_stack_frames`]: print total size and largest component.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant