Refactor error_helper and around

[asl]

This is a next step around messages emission refactoring. Essentially:

• Use C++17 features to reduce code duplication and modernize code, use universal references instead of passing by value
• Get rid of varargs for parser errors, use variadic templates instead
• Simplify code here and there getting rid of cstrings
• Unify object => string conversion

Things are a bit messy for the latter. We are having: toString, dbprint (that are different) and sometimes explicit operator<<. Plus, we define operator<< in a global namespace (in log.g, and some IR classes depend on this!) and call dbprint from there. However, for error messages, etc. we do not want to use operator<< (that is default implementation for boost::format for user-defined types) and use explicit toString.

So, this PR tries to do some consolidation of conversion to strings:

• Everything is moved to stringify.h, so log.h is all about logging
• We define operator<< to use toString, if available. If not, we try to delegate to dbprint

[ChrisDodd]

• We define operator<< to use toString, if available. If not, we try to delegate to dbprint

This seems backwards as operator<< is mostly (only?) used for logging, so it should try to use dbprint in preference to toString -- toString is for user-facing messages (removes any interal cruft) while dbprint is for logging/debugging (includes the internal cruft as that may be important for understanding what is going on). Changing this will significantly impact logging, making it less useful.

[asl]

This seems backwards as operator<< is mostly (only?) used for logging,

That's exactly the problem :(

1. boost::format uses operator<< for user types. So, we'd either need to be explicit with toString, or we'll end with dbprint output
2. Some code really does operator<< for user-facing things

So, maybe, we'd be explicit? And remove operator<< at all? So, there will be dbprint and toString and they will not mix with each other?

[ChrisDodd]

This seems backwards as operator<< is mostly (only?) used for logging,

That's exactly the problem :(

1. boost::format uses operator<< for user types. So, we'd either need to be explicit with toString, or we'll end with dbprint output
2. Some code really does operator<< for user-facing things

So, maybe, we'd be explicit? And remove operator<< at all? So, there will be dbprint and toString and they will not mix with each other?

Ugh -- that would require rewriting all of the LOG statements everywhere, including all the backends (which tend to rely on them quite a bit). That was why we had error_helper explicitly try to call toString where possible rather than using boost::format.

Maybe we could add a DBPrint::error_msg flag and have dbprint fall back to toString style cleanup for user-facing error messages and use that in error_helper to avoid getting cruft in error messages (the BUG messages should probably continue to use dbprint as those aren't really user-facing, so detail is better there -- "clean" release builds tend to catch CompilerBug exceptions and print a generic "Internal Error" message rather than the BUG message.)

[asl]

@ChrisDodd Ok. I moved to opposite direction (dbprint then toString). Let's see where we will land in the end!

[fruffy]

#4663 could help with this.

[asl]

@fruffy @ChrisDodd @vlstill

Will you please take a look when you will have a chance? I am having other PRs in the pipeline that are related to various strings aspects and they are a bit conflicting with each other to keep everything downstream :)

Thanks!

[ChrisDodd]

This should be ok, but I think the idea of unifying toString and dbprint with an additional flag in dbprint.h is a good way to go in the future.

[asl]

This should be ok, but I think the idea of unifying toString and dbprint with an additional flag in dbprint.h is a good way to go in the future.

Yes, I already opened #4698 to track this!