Removed broken test #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closed
sethfowler
added a commit
to sethfowler/p4c
that referenced
this pull request
May 2, 2017
The main refactoring taking place in this PR is to port the P4-14 and P4-16 lexers and parsers to use the C++ modes of Flex and Bison. In C++ mode, Flex generates a lexer that reads from a `std::istream` object instead of a file descriptor. That produces a bit of an impedance mismatch, because typically before we parse anything we run it through the C preprocessor via `popen()`, and `popen()` uses C `FILE*`-based I/O rather than iostreams. The C++-11 standard library does not include a `FILE*` wrapper that produces an `std::istream`. If we don't want to write and maintain one ourselves (and I'd argue we don't) that leaves us with three options: 1. Stop using `popen()` and implement the subset of C preprocessor features we need directly. 2. Read the entire file in and wrap it in a `std::stringstream` or similar. This obviously isn't as efficient as it could be. 3. Use Boost's IOStreams library to do the job more efficiently. In the large term, my view is that p4lang#1 is the best choice, but in the short run p4lang#3 seems like a win with no real downsides other than adding another dependency. (It's only an additional dependency on Ubuntu, which splits Boost into a number of small packages. On macOS there's actually no change.) In the interest of getting this PR landed ASAP, I've actually implemented both p4lang#2 and p4lang#3, so the Boost IOStreams dependency is optional. I would vastly prefer to make it mandatory, though.
sethfowler
added a commit
to sethfowler/p4c
that referenced
this pull request
May 3, 2017
The main refactoring taking place in this PR is to port the P4-14 and P4-16 lexers and parsers to use the C++ modes of Flex and Bison. In C++ mode, Flex generates a lexer that reads from a `std::istream` object instead of a file descriptor. That produces a bit of an impedance mismatch, because typically before we parse anything we run it through the C preprocessor via `popen()`, and `popen()` uses C `FILE*`-based I/O rather than iostreams. The C++-11 standard library does not include a `FILE*` wrapper that produces an `std::istream`. If we don't want to write and maintain one ourselves (and I'd argue we don't) that leaves us with three options: 1. Stop using `popen()` and implement the subset of C preprocessor features we need directly. 2. Read the entire file in and wrap it in a `std::stringstream` or similar. This obviously isn't as efficient as it could be. 3. Use Boost's IOStreams library to do the job more efficiently. In the large term, my view is that p4lang#1 is the best choice, but in the short run p4lang#3 seems like a win with no real downsides other than adding another dependency. (It's only an additional dependency on Ubuntu, which splits Boost into a number of small packages. On macOS there's actually no change.) In the interest of getting this PR landed ASAP, I've actually implemented both p4lang#2 and p4lang#3, so the Boost IOStreams dependency is optional. I would vastly prefer to make it mandatory, though.
sethfowler
added a commit
to sethfowler/p4c
that referenced
this pull request
May 4, 2017
The main refactoring taking place in this PR is to port the P4-14 and P4-16 lexers and parsers to use the C++ modes of Flex and Bison. In C++ mode, Flex generates a lexer that reads from a `std::istream` object instead of a file descriptor. That produces a bit of an impedance mismatch, because typically before we parse anything we run it through the C preprocessor via `popen()`, and `popen()` uses C `FILE*`-based I/O rather than iostreams. The C++-11 standard library does not include a `FILE*` wrapper that produces an `std::istream`. If we don't want to write and maintain one ourselves (and I'd argue we don't) that leaves us with three options: 1. Stop using `popen()` and implement the subset of C preprocessor features we need directly. 2. Read the entire file in and wrap it in a `std::stringstream` or similar. This obviously isn't as efficient as it could be. 3. Use Boost's IOStreams library to do the job more efficiently. In the large term, my view is that p4lang#1 is the best choice, but in the short run p4lang#3 seems like a win with no real downsides other than adding another dependency. (It's only an additional dependency on Ubuntu, which splits Boost into a number of small packages. On macOS there's actually no change.) In the interest of getting this PR landed ASAP, I've actually implemented both p4lang#2 and p4lang#3, so the Boost IOStreams dependency is optional. I would vastly prefer to make it mandatory, though.
sethfowler
added a commit
to sethfowler/p4c
that referenced
this pull request
May 4, 2017
The main refactoring taking place in this PR is to port the P4-14 and P4-16 lexers and parsers to use the C++ modes of Flex and Bison. In C++ mode, Flex generates a lexer that reads from a `std::istream` object instead of a file descriptor. That produces a bit of an impedance mismatch, because typically before we parse anything we run it through the C preprocessor via `popen()`, and `popen()` uses C `FILE*`-based I/O rather than iostreams. The C++-11 standard library does not include a `FILE*` wrapper that produces an `std::istream`. If we don't want to write and maintain one ourselves (and I'd argue we don't) that leaves us with three options: 1. Stop using `popen()` and implement the subset of C preprocessor features we need directly. 2. Read the entire file in and wrap it in a `std::stringstream` or similar. This obviously isn't as efficient as it could be. 3. Use Boost's IOStreams library to do the job more efficiently. In the large term, my view is that p4lang#1 is the best choice, but in the short run p4lang#3 seems like a win with no real downsides other than adding another dependency. (It's only an additional dependency on Ubuntu, which splits Boost into a number of small packages. On macOS there's actually no change.) In the interest of getting this PR landed ASAP, I've actually implemented both p4lang#2 and p4lang#3, so the Boost IOStreams dependency is optional. I would vastly prefer to make it mandatory, though.
sethfowler
added a commit
that referenced
this pull request
May 4, 2017
The main refactoring taking place in this PR is to port the P4-14 and P4-16 lexers and parsers to use the C++ modes of Flex and Bison. In C++ mode, Flex generates a lexer that reads from a `std::istream` object instead of a file descriptor. That produces a bit of an impedance mismatch, because typically before we parse anything we run it through the C preprocessor via `popen()`, and `popen()` uses C `FILE*`-based I/O rather than iostreams. The C++-11 standard library does not include a `FILE*` wrapper that produces an `std::istream`. If we don't want to write and maintain one ourselves (and I'd argue we don't) that leaves us with three options: 1. Stop using `popen()` and implement the subset of C preprocessor features we need directly. 2. Read the entire file in and wrap it in a `std::stringstream` or similar. This obviously isn't as efficient as it could be. 3. Use Boost's IOStreams library to do the job more efficiently. In the large term, my view is that #1 is the best choice, but in the short run #3 seems like a win with no real downsides other than adding another dependency. (It's only an additional dependency on Ubuntu, which splits Boost into a number of small packages. On macOS there's actually no change.) In the interest of getting this PR landed ASAP, I've actually implemented both #2 and #3, so the Boost IOStreams dependency is optional. I would vastly prefer to make it mandatory, though.
mihaibudiu
pushed a commit
that referenced
this pull request
Jul 14, 2021
…statement (#2836) * Fix dpdk regression failure: Duplicates declaration * Fix cpplint errors * Added checks to ensure parameters exist before accessing them * Fix PSA extern Register's implementation 1) Add missing regarray declarations 2) Fix read() method implementation * Updated spec.cpp as per review comments * Emit a warning if Register instantiation is found outside control block * Fixed a typo * Remove restriction for instantiation and invocation of register extern objects and methods in/from control blocks only * Conditional operator support for P4C-DPDK. - Disabled Midend predication pass to allow conditional operator to be splitted into if-else statement - Added a new test and reference output for conditional operator * Changing ternary match to exact in test program, updating the reference output * Added support for range and mask operations in transition select statement. Fixed few typos * Support mask operations in dpdk backend (#1) * Remove pass for inserting temporary mask variables * update reference output * Address review comments * DPDK backend: Add support for tuple expressions in transition select statement * Address review comments for tuple expression support * Use refmap to create label names, use ERR_UNSUPPORTED_ON_TARGET for a few errors * Update test files to include core.p4
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added support for resubmit and recirculate.