Add abseil string helpers

[asl]

Add abseil string manipulator helpers for

• 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.

[asl]

This required few breaking changes though:

• As there is custom formatter, things cannot be formatted via %s depending on implicit conversion to char*
• There is an implicit conversion to std::string_view now producing some breakage with Protobuf code as now we are having ambiguous implicit conversions. Unfortunately, we cannot (yet) make conversion to char* explicit, as lots of code relies on this, and this will be a topic for another PR

[fruffy]

Nice, maybe we should wait for #4964 to be merged to avoid compatibility issues?

[asl]

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]

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 char*.

[fruffy]

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 char*.

What are the planned changes for the next PR? Maybe you can stack it on this one so we can see?

[asl]

@fruffy @vlstill @ChrisDodd Will you please take a look when you will have a chance?

[fruffy]

@fruffy @vlstill @ChrisDodd Will you please take a look when you will have a chance?

Changes generally look good to me, I am waiting for comments by others since this is a breaking change. The Tofino breakage looks easy enough to fix. I will also push some more Tofino fixes later which could help this PR.

[ChrisDodd]

We really need multiple formatters for things like IDs and Nodes:

• one for use in error messages, where we output things in a form that the P4 programmer can understand
• one for use in logging messages, where we output things that the compiler developer needs to know in order to debug the compiler.

In the past, we've used toString() for the former and operator << for the latter. That means that the error and warning functions (and their helpers) will use toString() when converting things for % formats in the message, while LOG macros all use <<.

Where does abseil formatting fit in this? Is it for user messages or logging? Whatever the choice, it needs to be clearly documented.

[asl]

Where does abseil formatting fit in this? Is it for user messages or logging? Whatever the choice, it needs to be clearly documented.

This simplifies toString calls. operator<< are untouched (though many of those delegate to some toString calls, yes). The main intention here is to simplify explicit string_view calls when used in different APIs that are being converted to string_view's these days.

The converters are to simplify absl::StrCat / absl::StrFormat / absl::StrSubstitute / absl::StrAppend / absl::StrJoin calls, e.g.

-        std::string tcActionParam = absl::StrCat("\n\tparam ", paramName.string_view(), " type ");
+        std::string tcActionParam = absl::StrCat("\n\tparam ", paramName, " type ");

Or, instead of

name = absl::StrCat(absl::StrJoin(stack, ".", [](std::string *out, cstring s) {
                                 absl::StrAppend(out, s.string_view());
                             }), name.string_view())

we end with

name = absl::StrCat(absl::StrJoin(stack, "."), name);

There are all different ways to "convert" cstring or ID for printing in the codebase: c_str() calls, toString() calls, string_view() calls. I tried to clean the things as much as I can :)

I will add comment describing the intended usage.

[ChrisDodd]

There are all different ways to "convert" cstring or ID for printing in the codebase: c_str() calls, toString() calls, string_view() calls. I tried to clean the things as much as I can :)

For an ID at least, toString() and operator<< do very different things -- toString() give you the ID as it appears in the P4 source code, while operrator<< gives you the uniquified/mangled name (so different versions of the same ID in different scopes will look different).

[asl]

For an ID at least, toString() and operator<< do very different things -- toString() give you the ID as it appears in the P4 source code, while operrator<< gives you the uniquified/mangled name (so different versions of the same ID in different scopes will look different).

That's correct. But neither user-side error reporting, nor debug printing are affected / changed / or even touched. These are just helpers to simplify the usage of abseil string manipulation functions. So, I might just put wrong title of the PR. To put things simpler: here we are entirely in the toString domain.