Anton Korobeynikov

> The language spec is quite clear about the semantics here: Thanks for the clarification! Then yes, there might be multiple "instances" of `Type_Boolean`, etc. and it is expected that...

> Yes, this seems the way to go to avoid future bugs in the code. +1. All unique nodes should have closed `operator new`.

So, there are few important points to consider here. 1. First of all, there are no "LLVM preprocessor library" or "GNU preprocessor library". The preprocessor is an inherent part of...

Just some loud thinking. Now we are having an integer typeid for each node, so could order according to these. And only for same typeid we can use something "internal"

@fruffy By "performance" you mean that it is currently slow?

Some additional bits here sans `boost::format` and `boost::multiprecision`: - [x] control-plane/p4RuntimeSymbolTable.cpp uses `boost::split` and `boost::adaptors::reverse`. We can readily replace the latter with `iterator_range`. And the first... well, if abseil would...

For `boost::container::flat_map` dependency I'd rather pull small header-only thing into `lib`. I believe I even had some implementation somewhere.

> It looks like the open-source code does not even use boost::regex. So we may not have to worry about this particular replacement. And for downstream you might try re2

@fruffy I might have some spare time today, do you want me to replace boost string stuff with their abseil equivalents?

> That would be very welcome! Which boost string things concretely? I believe it's mostly `split`. See https://github.com/p4lang/p4c/issues/3898#issuecomment-1961731053