[cfe-dev] [RFC][C++]: Option to emit a run-time call when throw statement is used with `-fno-exceptions` instead of diagnosing an error.

[via cfe-dev]

The current behavior of `throw <object-instance>` is to diagnose it as a hard error
unless it's in a system header. This makes integrating codebases that use exceptions
difficult without resorting to macro tricks and alike. 

The proposal is to add a driver option to allow the compiler to turn such cases into
runtime calls to a function like `__cxa_throw_noexcept(...)` stepping into another
frame, with the opaque handle pointing to the exception that would be thrown in that
case. This is more flexibile than std::terminate() approaches as it allows the 
application vendor to define such function in their code (if the driver flag is
enabled) and implement a more graceful failure (ie. symbolicated stack trace) without
the need to change existing code.

Rationale is that is makes large codebases compiled include components that make use
of throw without splitting them into separate archives, in source form requires
changing the code throwing the exceptions which is not always easy to merge back into
an upstream project. This also opens the possibility of a less vague variant of such
ABI function if RTTI data is enabled but exceptions are disabled where the application
can implement custom logic for handling specific types of objects.

Majority of cases would still require termination but this option allows existing code
to compile with exceptions disabled and without having to maintain downstream forks
of various projects because they use exceptions. In such cases the application is free
to decide what to do without the need for any refactoring and while this opens up room
for fairly dangerous errors, this assumes that whoever is using that compiler flag is
aware of exception basics and that such an ABI function cannot resume execution normally,
it is better to allow the author to decide how to handle the case (ie. crash dump, signal,
call continuation or any other form of context switch). With or without RTTI such a
function could also include source context of the throw in case where exceptions are
fatal and source/location data is desired in the crash report.

If such flag is enabled, it is up to the application to provide an implementation
of `__cxa_throw_noexcept` dealing with that behavior which also acknowledges that the
author understands the semantics of it (ie. the current frames are likely trashed, there
may be lock guards held, which would have to be accounted for somehow). The proposal
is aimed at environments with a alternative standard library which may do this accounting
in application defined fashion such as storing non-critical (non-spinlocks) locks inside
a thread control block, in which case such cases could even be considered recoverable
giving `throw` an opportunity to exist even in embedded environments.

Thank you.
- Kristina