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

static tuple used as a match arm yields weird error #14576

Closed
alan-andrade opened this issue Jun 1, 2014 · 4 comments
Closed

static tuple used as a match arm yields weird error #14576

alan-andrade opened this issue Jun 1, 2014 · 4 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR)

Comments

@alan-andrade
Copy link
Contributor

hello rusties,

I have a program similar to this:

type Foo = (i32, i32);
static ON: Foo = (1, 1);
static OFF: Foo = (0, 0);

fn main() {
    match (1, 1) {
        ON => { println!("{}" , ON) },
        OFF => { println!("{}" , OFF) }
    }
}

When I try to compile I get the following error:

<anon>:2:18: 2:24 error: unsupported constant expr
<anon>:2 static ON: Foo = (1, 1);
                          ^~~~~~

Is this behavior expected?
http://j.mp/1kjSiMc

@japaric
Copy link
Member

japaric commented Jun 1, 2014

I'd expect this to fail with "non-exhaustive pattern".

cc @Kimundi (probably related to RFC #17)

@huonw
Copy link
Member

huonw commented Jun 1, 2014

The following all have the same error message/cause but with slightly different types: #6533, #13626 and #13731.

@ghost
Copy link

ghost commented Jun 9, 2014

This is interesting as to fix it will probably require rewriting the constant expressions into pattern nodes and inlining them in the pattern matrix.

@ghost
Copy link

ghost commented Jul 6, 2014

I started a branch on this but I think it's a bit of a dead-end. What I think would ideally happen is the following:

  • Statics get type checked.
  • For each PatIdent that references a static, that static gets compile-time evaluated into an equivalent Pat node.
  • Patterns get type checked, sanity checked and codegened.

This introduces mutability to the AST, which is a major change to what the current design is. I'm all ears for other solutions. :-) I'd love to fix this as this is just one of several reports on the same issue.

bors added a commit that referenced this issue Jul 19, 2014
This is accomplished by rewriting static expressions into equivalent patterns.
This way, patterns referencing static variables can both participate
in exhaustiveness analysis as well as be compiled down into the appropriate
branch of the decision trees that match expressions are codegened to.

Fixes #6533.
Fixes #13626.
Fixes #13731.
Fixes #14576.
Fixes #15393.
@bors bors closed this as completed in fba1194 Jul 19, 2014
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
Fix explicit deref problems in closure capture

fix the `need-mut` part of rust-lang#14562

Perhaps surprisingly, it wasn't unique immutable borrow. The code still doesn't emit any of them, and I think those won't happen in edition 2021 (which is currently the only thing implemented), since we always capture `&mut *x` instead of `&mut x`. But I'm not very sure about it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants