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
What's happening here is the same control resolver is instantiated multiple times, once from the foo control and once from the bar control. Because generated rust names for tables are based entirely on the name of control they are a part of and the name of the table e.g. $control_table_$table this means that multiple instantiations will cause collisions. The code generated from the P4 below at time of writing is recorded in this gist.
One possible solution is to make the generated names more specific. Another arguably much better solution would be to not have control objects be implicitly global, but rather have them be local to the scope in which they're created. This is a pretty major change and will require a lot of rework, but is probably a better path forward.
- codegen/rust: consistent bit/int literal byte order
- p4rs: consistent bitvec dumps
- checker: basic assignment type checking
- add double instantiation example from issue #8
- boundary services e2e NAT working with sidecar-lite
- update examples based on consistent byte order literals
The following P4 generates bad rust output.
What's happening here is the same control
resolver
is instantiated multiple times, once from thefoo
control and once from thebar
control. Because generated rust names for tables are based entirely on the name of control they are a part of and the name of the table e.g.$control_table_$table
this means that multiple instantiations will cause collisions. The code generated from the P4 below at time of writing is recorded in this gist.One possible solution is to make the generated names more specific. Another arguably much better solution would be to not have control objects be implicitly global, but rather have them be local to the scope in which they're created. This is a pretty major change and will require a lot of rework, but is probably a better path forward.
The text was updated successfully, but these errors were encountered: