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
P4 doesn't really have a standard build system (to my knowledge), but to properly handle preprocessors like #include and conditionals + macros, a specific compiling context has to be assumed. Clangd (using C++ LSP tool as an example because many other languages don't have to deal with the complexities of complicated preprocessors) solves this problem by standardizing a compilation database (more context here), and integrating with common build systems to generate it automatically. I wonder if something similar is needed for p4analyzer?
Some p4c compiler options that are particularly relevant are the following (similar to C/C++):
These could change how a P4 code should be interpreted. For example, when doing "jump to definition", the definition might be in a #if branch pending on a macro supplied from -D.
The text was updated successfully, but these errors were encountered:
We plan to handle this by adding include path and macro definition settings to the VS Code extension. On the analyzer-core side, these settings would then simply seed the preprocessor state, coming in as a Salsa input that the preprocessing steps depend on. This should be general enough to fit whatever build system the user works with. It's also possible to define them in a directory-specific VS Code file (./.vscode/settings.json), so they can be handled by VCS.
We might look into some kind of tighter, build system -specific integration if there's significant interest from the community.
This is the main blocker (for me at least) for making the analyzer generally applicable. I have been successfully running p4analyzer as part of a Sublime-LSP setup. However, for most programs I get something of this nature:
[crates/analyzer-core/src/lib.rs:251] &pp.errors = [
(
(
FileId(
Id {
value: 1,
},
),
0..19,
),
"Could not find core.p4",
),
(
(
FileId(
Id {
value: 1,
},
),
52..74,
),
"Could not find v1model.p4",
),
]
Is it possible already to provide some form of include argument to the analyzer? I am not sure whether I understood the comment correctly.
P4 doesn't really have a standard build system (to my knowledge), but to properly handle preprocessors like
#include
and conditionals + macros, a specific compiling context has to be assumed. Clangd (using C++ LSP tool as an example because many other languages don't have to deal with the complexities of complicated preprocessors) solves this problem by standardizing a compilation database (more context here), and integrating with common build systems to generate it automatically. I wonder if something similar is needed for p4analyzer?Some p4c compiler options that are particularly relevant are the following (similar to C/C++):
-D
can be used to define a macro to be used by the preprocessor.-I
can be used to add directory to include search path.These could change how a P4 code should be interpreted. For example, when doing "jump to definition", the definition might be in a
#if
branch pending on a macro supplied from-D
.The text was updated successfully, but these errors were encountered: