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

"Compiler Bug: At this point in the compilation typechecking should not infer new types anymore, but it did." with select statement and enum types #3333

Closed
apinski-cavium opened this issue May 17, 2022 · 0 comments · Fixed by #3341
Assignees
Labels
bug This behavior is unintended and should be fixed. fixed This topic is considered to be fixed.

Comments

@apinski-cavium
Copy link

While trying to understand the type rules for select since I would have expected serializable enums to "decay" (implict cast) into their underlaying type (but it does not and it is partly inconsistent with the rest of the specifications really) I found this issue:
Take:

enum bit<8> myenum {  value = 0 }
parser MyParser1(in  myenum a) {
    state start {
        transition select(a) {
                1 .. 22: state1;
                _: accept;
        }
    }
    state state1 {
        transition accept;
    }
}

With p4c we get:

t.p4(8): [--Werror=type-error] error: SelectExpression
        transition select(a) {
                   ^
  ---- Actual error:
  t.p4(1): Cannot unify type 'bit<8>' with type 'myenum'
  enum bit<8> myenum
              ^^^^^^
  ---- Originating from:
  t.p4(1): 'match' case label type 'bit<8>' does not match expected type 'myenum'
  enum bit<8> myenum
              ^^^^^^
In file: /home/apinski/src/p4/p4c/frontends/p4/typeChecking/typeChecker.cpp:161
Compiler Bug: At this point in the compilation typechecking should not infer new types anymore, but it did.

Note the error message also does not point to which case lable either, it just points to the enum type but that is a different issue.

@mihaibudiu mihaibudiu added the bug This behavior is unintended and should be fixed. label May 18, 2022
@mihaibudiu mihaibudiu self-assigned this May 18, 2022
@mihaibudiu mihaibudiu added the fixed This topic is considered to be fixed. label May 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This behavior is unintended and should be fixed. fixed This topic is considered to be fixed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants