Handle @max_group_size annotation when generating P4Info
This annotation is standardized by the P4Runtime specification and
enables the P4 programmer to specify the maximum group size (sum of
weights across all members in a group) for a given v1model / PSA
action selector.
- template combining P4Control and P4Parser inlining
- extend avoidance of unnecessary copying to parser inlining
16cf341...
by
Calin Cascaval <email address hidden>
add a bound to the number of errors that are printed before exiting (#1817)
add a bound to the number of errors that are printed before exiting
The compiler error reporting is based on the principle that printing
as many errors as possible will allow users to fix multiple of them in
a single compilation pass. However large number of errors is usually
too hard to handle, and people will incrementally fix errors as they
go. What is that magic number? Clang uses 20, which seems quite
reasonable, so we use that as a base.
We also provide the `ErrorReporter::setMaxErrorCount` function, so
that different backends can chose their own threshold matching their
user's expectations.
And finally, a bit more cleanup to remove redundancies in the error
reporting code. The main reason for splitting error_helper and
bug_helper functions into a separate header is to avoid circular
include dependencies:
error.h -> error_reporter.h -> exceptions.h -> error.h
* add argument to set maxErrorCount and use it for tests that exceed the limit
Make --p4runtime-entries outputs more conformant to P4Runtime spec
See #1805
* omit don't care matches
* toggle off value bits which are masked off for ternary and LPM
* emit a warning for ignored @priority annotation, and generate correct
priority values
* I couldn't move to the canonical binary string representation for
bit<W> values because it is not currently supported by p4lang/PI
