When the user gives relative path names for p4 files, report
those in error messages (etc.). The SourceManager can/does
resolve those to absolute path names.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Implement a generic visitor for components of a P4 program and use
it to start P4 code generation (according to the behavioral model).
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Make it possible to output formatted error messages using a
flexible API that includes an ability to specify styles and
formatters.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
For types, make it optional to return a default value. While default
values for some types are meaningful, they are not meaningful for all
types (e.g., Action, Control, Parser, Parser state, etc.).
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Support calling (invoking) a Control. There is still plenty more to
do here, but we are off to a good start.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Parameterize Runtime (nee ParserRuntime) so that it can run anything
that is LibraryCallable. TODO: Refactor its API -- left mostly as
it was because changing unit tests will be laborious.
The compilation code was written as a precursor for implementation
with macros. The updates in this commit make the switch.
There is still plenty to do:
1. Comment Walker.
2. Comment Macros.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Allow the user to customize the evaluation/execution of expressions/
statements with something that implements functions that perform
those tasks. This additional functionality will make it possible for
the "classic" evaluator not to waste time checking for the presence
of interlopers and give implementers additional customization opportunities.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Centralize the execution of statements and evaluation of expressions
so that the user can specify a debugging "callback" after every
execution/evaluation.
The callback can be used for myriad things, but it seems likely that
it will be useful for implementing:
1. Testing
2. Debugger
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Add support functions to check whether a (block of) statement(s) contains
any statements that should not appear in that block (e.g., switch in
an action).
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
When a function is called, if there is an (in)out parameter,
make sure that updated values are propogated to the calling
function.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
The type system (and the value system) now include attributes
for each type (things like direction, const-ness).
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Add support for directions on parameters and attributed types. The
latter is necessary to support the former, but is not limited to
the direction use case. An attributed type is a P4 type with attributes
(like its direction, whether it is read only, etc.) Other attributes
will be added in the future.
Changes necessary to support attributed types include:
1. Global instances tracked during compilation are not attributed
types and not simply types.
2. (future) Type checking will have to make sure that a types
attributes do not affect type compatibility.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
By adding an expected type to the compilation context, it is
now possible for type checking to occur on keyset expressions
and return statements at the moment that they are being compiled.
Previously, it was necessary to tentatively compile them and then
typecheck afterward.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Refactor the class hierarchy for parser states so that
there is a parser state that acts more like a type and
one that acts more like a value (the latter, then, serves
as the base class for the other instantiated parser states).
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Fields were not given default values when a struct was declared
without initializers.
Also, cleanup code in the helper function for binary operations
on struct instances.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Will Hawkins