You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This test examples/checker_tests/bad/issue2260-1.p4 is expecting that implicit casts aren't done on results of generic functions, or something like that. Our typechecker doesn't have any trouble with it, so I think it's fine.
The text was updated successfully, but these errors were encountered:
./issue2260-1.p4i(11): [--Werror=type-error] error: f
bit<8> y = f(255);
^^^^^^
---- Actual error:
'int' type can only be unified with 'int', 'bit<>', or 'signed<>' types, not with '<returned type>'
---- Originating from:
./issue2260-1.p4i(6): Return type 'T' cannot be used for '<returned type>'
T f<T>(T x) {
^
Where 'T' is bound to 'int'
---- Originating from:
./issue2260-1.p4i(6): Function type 'f' does not match invocation type '<Method call>'
T f<T>(T x) {
^
./issue2260-1.p4i(11)
bit<8> y = f(255);
^^^^^^
Seems like p4c is doing the right thing. It's not accepting returning an arbitrary length int when f is invoked. On the other hand, Petr4 somehow isn't checking this. We need to look into what Petr4 is doing for method invocation with a generic type.
This test
examples/checker_tests/bad/issue2260-1.p4
is expecting that implicit casts aren't done on results of generic functions, or something like that. Our typechecker doesn't have any trouble with it, so I think it's fine.The text was updated successfully, but these errors were encountered: