[clang] [Clang][CodeGen] Emit “trap reasons” on UBSan traps (PR #145967)

[Dan Liew via cfe-commits]

delcypher wrote:

@PiJoules 

> Moving forward, I think it would be good to gather consensus on a better scheme with respect to verbose messages handled by the debugger. Rather than baking a custom format into the function name, we think it's more portable and straightforward to use standard dwarf features. If we don't end up using DW_AT_description in this PR, I think it would be good to at least ensure that using this mangled format isn't a permanent status quo and we leave room for incremental improvements in the future towards a more portable standardized approach. Such a scheme definitely needs more flushing out than what I posted earlier in this thread, so I'll likely post an RFC on discourse with a more formal proposal some time in the future.

I don't think we are strongly tied to the mangled function name format (in fact we've already changed the mangling once internally already). If we do introduce a new approach based on `DW_AT_description` then provided we can have LLDB understand both the old (mangled function name) and new approach (uing `DW_AT_description`) for encoding the trap reasons for a few releases (so that newer debuggers can handle older binaries) then I suspect that would be fine. @Michael137 @adrian-prantl may want to chime in though.

An RFC on a more fleshed out version of what you sketched out would be great. When writing it though please consider that UBSan is not the only use case for this. In particular

* `-fbounds-safety` (implemented in the open source Swift fork of clang) uses this mechanism too in an incredibly similar way. 
* `__builtin_verbose_trap` (which is already adopted in libcxx IIRC) uses the current mechanism.
* Swift uses a very similar mechanism for its traps but the implementation is independent from Clang. Swift's implementation is in fact the inspiration for how we implemented representing trap messages in Clang.

If  `DW_AT_description` just encodes a static string that would be general enough for `-fbounds-safety` and `__builtin_verbose_trap` but as soon as we start talking about "fake" arguments to the "fake" function in debug info then things get much more complicated and doesn't necessary generalize.

https://github.com/llvm/llvm-project/pull/145967