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

Questions on where match_kind values should be allowed #3091

Closed
jfingerh opened this issue Feb 23, 2022 · 4 comments · Fixed by #3099
Closed

Questions on where match_kind values should be allowed #3091

jfingerh opened this issue Feb 23, 2022 · 4 comments · Fixed by #3099
Assignees
Labels
bug This behavior is unintended and should be fixed. fixed This topic is considered to be fixed.

Comments

@jfingerh
Copy link

The attached test program demonstrates some places where it appears that values of type match_kind, e.g. exact, ternary, appear to be unsupported by the current p4c compiler. See the README.md file in the attached zip file for which p4test commands succeed, and which give errors. It is not clear to me if any of the ones that give errors should succeed, or not. Most of them involve attempts to use a match_kind as a constructor parameter of an extern object constructor.
match-kind-issues1.zip

@jfingerh
Copy link
Author

Example program was inspired by investigating how to use the externs defined in this PR: #2739

@mihaibudiu
Copy link
Contributor

There are several examples that should never work:

const tuple<match_kind> exact_once = {exact};
ValueLookupTable<exact_once, bit<8>, bit<16>>(1024) velut;

This won't work because exact_once is not a type, it is a variable.

Same for this:

    ValueLookupTable<(tuple<match_kind>) {exact}, bit<8>, bit<16>>(1024) lut3;

{exact} is a value, not a type, and in the type parameters you can only have types. You can have values in the constructor arguments.

@mihaibudiu
Copy link
Contributor

But this should work:

    ValueLookupTable<tuple<match_kind>, bit<8>, bit<16>>(1024) lut3;

@mihaibudiu mihaibudiu added the bug This behavior is unintended and should be fixed. label Feb 26, 2022
@mihaibudiu mihaibudiu self-assigned this Feb 26, 2022
@mihaibudiu mihaibudiu added the fixed This topic is considered to be fixed. label Feb 26, 2022
@mihaibudiu
Copy link
Contributor

More precisely, see a working example in #3099.
I will submit a fix for the spec too.

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