Add XFAIL P4_14 test program that fails because of issue #1694 (#1710)
* Add XFAIL P4_14 test program that fails because of issue #1694
It is nearly identical to the test program p414-special-ops.p4
proposed to be added in the PR #1704, except this program explicitly
modifies metadata fields after a resubmit, recirculate, or clone
operation is performed, and the STF tests will only pass if the
behavior of the packet processing is that the metadata fields are
preserved at the _end_ of ingress/egress processing, _not_ the values
that the metadata fields have at the time of the
recirculate/resubmit/clone primitive operation call.
This is consistent with the P4_14 language specification, at least as
of the clarifications made in v1.0.5 of the specification.
Add XFAIL P4_14 test program that fails because of issue #1669 (#1709)
* Add XFAIL P4_14 test program that fails because of issue #1669
It is nearly identical to the test program p414-special-ops.p4
proposed to be added in the PR #1704, except that program explicitly
lists individual fields to be preserved during resubmit
etc. operations, whereas this one gives the name of an entire metadata
'header' to be preserved.
For p414-special-ops-2-bmv2.p4, p4c as of this writing introduces
temporary metadata variables and preserves those instead of the ones
named in the source file, and since the STF packet tests cases rely
for their correct operation on the metadata fields being preserved,
they fail.
* Add expected compiler output files for new test program
Handle complex headers (with nested structs) in P4Info generation (#1708)
The P4Info generation code now handles complex headers by flattening
them. This is independent from the FlattenHeaders pass, which is a
midend pass. This code is much simpler and has no dependency on non
frontend pass. It simply performs a "local" flattening of a given
Type_Header, without updating any program references. It also preserves
the fully-qualified name using a @name annotation (unlike the
FlattenHeaders pass), along with annotations of the nested
fields. Because of the local nature of this flattening, it seemed silly
to write an actual pass (I tried and it was clumsy, with a call to
visitAgain).
The flattening is performed wherever the p4RuntimeSerializer has to deal
with header types, so only 2 places: for controller headers and in the
typeSpecConverter.
264da2c...
by
Calin Cascaval <email address hidden>
error reporting (#1646)
* fix warnings and name overload
Fixes a couple of warnings, and in particular the one in
parserControlFlow.cpp looks like a genuine error, where the variable
is redefined in each iteration.
* add support for typed errors
Addresses the issue of repeated error and warning messages when
compiler passes are repeated, by introducing error/warning types, and
an error catalog. Error types classify the errors and impose a format
that allows the compiler to automatically filter repeated
messages. The filtering is based on the type of error and the source
code location of the object that reports the error. Thus, it allows
multiple error types per source code line, and ensures that only one
error is reported even if the message is raised multiple times. Error
codes and formats are defined in `lib/error_catalog.[h,cpp]`. Backends
can extend the codes and formats as needed (and they are encouraged to
do so).
To ease the transition to typed errors and warnings, free form
messages whose first argument (`%1%`) is an `IR::Node` (or more
precisely a class that implements `Util::IHasSourceInfo` interface),
will be converted automatically to typed errors that use the format
argument of the message rather than the error catalog predefined
formats.
Also introduces the `FATAL_ERROR` macro to print a message and raise
an CompilationError exception.
And finally adds documentation on how to use to the coding standards.
* convert bmv2 errors to typed errors
* convert to typed errors and warnings in the frontend
* revert robotic change for arguments that are strings
* refactor the error catalog
Refactor the error catalog into a singleton class and keep user format
messages combined with a error/warning title.
Define additional classes of warnings to cover the majority of warnings
in the frontend and the three open-source backends.
* introduce error and warning types.
* update reference outputs
* addresses reviewer comments
More cleanup on the error messages:
- remove duplicated printing of the leading object
- add ERR_TYPE_ERROR as an error type to enable tracking all uses of fields
- add ERR_UNSUPPORTED_ON_TARGET error type
- fix spacing
- rebased on latest master
* allow errors for all occurrences of a non-defined field
