Add abseil formatters #4971
Add abseil formatters #4971
Conversation
asl
added
core
|
This required few breaking changes though:
|
|
Nice, maybe we should wait for #4964 to be merged to avoid compatibility issues? |
I not quite sure. Even more, given the size of the backend, doing project-wide refactoring and changes could be prohibitely expensive as soon as it will be merged in. |
asl
force-pushed
the
absl-stringify
branch
2 times, most recently
from
ba1e77b
to
40d0a66
Compare
|
Tofino failures are due to mentioned protobuf ambiguities. They will likely will be easier to fix after the subsequent PR that removes implicit conversion to |
What are the planned changes for the next PR? Maybe you can stack it on this one so we can see? |
| @@ -147,7 +147,7 @@ class BFRuntimeArchHandler : public P4RuntimeArchHandlerCommon<arch> { | |||
| } | |||
| auto *externType = p4info->add_externs(); | |||
| externType->set_extern_type_id(static_cast<p4rt_id_t>(typeId)); | |||
| externType->set_extern_type_name(typeName); | |||
| externType->set_extern_type_name(typeName.string_view()); | |||
There was a problem hiding this comment.
Why is this required here?
There was a problem hiding this comment.
As I mentioned, Protobuf strings have two constructors: from const char* and string_view. In order to use cstring directly we need to make this conversion explicit.
There was a problem hiding this comment.
And I assume the reason is that we also have an implicit conversion to const char*? Is the follow-up PR working on that? Maybe it should be first.
There was a problem hiding this comment.
Right. And this is misused in many places, e.g. passing cstring's to C functions like strlen, improper checks for nulls, etc. :)
There was a problem hiding this comment.
I added commits from subsequent PR
There was a problem hiding this comment.
The changes paired with the subsequent Pr look much better to me. Definitely an improvement.
There was a problem hiding this comment.
I might missed few cases here and there. However, I believe that we do not need lambdas in the example like in #4951 (comment) anymore.
| @@ -191,7 +191,7 @@ class cstring { | |||
| std::string_view string_view() const { | |||
| return str ? std::string_view(str) : std::string_view(""); | |||
| } | |||
| explicit operator std::string_view() const { return string_view(); } | |||
| operator std::string_view() const { return string_view(); } | |||
There was a problem hiding this comment.
Would add a comment here why this shouldn't be explicit.
There was a problem hiding this comment.
This was already discussed in #4688. But essentially: we are going to make interface similar to std::string essentially allowing string_view into corresponding cstring-backed storage. This would fix lots of cstring misuse.
- cstring - IR::Node - IR::ID This improves the code itself as we no longer need to do explicit .toString() / .string_view() calls. Also, this prints directly to sink, providing some performance improvements. Signed-off-by: Anton Korobeynikov <[email protected]>
Signed-off-by: Anton Korobeynikov <[email protected]>
…ambiguous Signed-off-by: Anton Korobeynikov <[email protected]>
Signed-off-by: Anton Korobeynikov <[email protected]>
Signed-off-by: Anton Korobeynikov <[email protected]>
Add abseil formatters for
This improves the code itself as we no longer need to do explicit .toString() / .string_view() calls. Also, this prints directly to sink, providing some performance improvements.