David Truby

Here's the upstream libstdc++ bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90397

Assuming I understand correctly that you mean the places where it outputs to a `std::stringstream` before writing that to a file, llvm has a `raw_string_ostream` class that is pretty much...

The non-standard facility is faster because it makes more assumptions about what the type of the buffer is. Additionally it's not templated so it can be forward declared safely. The...

I haven't had the time to port it yet. However I think it's a somewhat academic discussion as LLVM forbids the use of the standard streams library for a number...

Sure, stringstream is not problematic in the same way. However, most llvm libraries only provide conversions to raw_ostream& etc, and raw_ostream is preferred over standard streams regardless for [other reasons](https://llvm.org/docs/CodingStandards.html#use-raw-ostream).

Why define our own macro when something suitable already exists elsewhere in the project?

Hi Kiran, thanks for looking at this. At a glance I think we can replace our die function with something like the following (I haven't tried to compile this code...

I believe CMake's RelWithDebugInfo build type leaves assets on? That should help with debugging optimised builds if so. The advantage of using llvm_unreachable and assert is they both use compiler...

What I said seems to be untrue, RelWithDebInfo still has -DNDEBUG. However, LLVM does have an LLVM_ENABLE_ASSERTIONS variable in cmake to force both `assert` and `llvm_unreachable` on in any build...

Doesn't `debug_assert` in Rust do the same thing as `assert` here? As in, it gets disabled in optimised/release builds? It's not so much that potential UB is intended as it...