[LLVMdev] LLVM asserts

[Óscar Fuentes]

Eli Friedman <eli.friedman at gmail.com> writes:

>> As LLVM is really a library it should behave like one and not just abort the
>> whole process on an assert.
>
> This isn't Java; if we hit an assert, it's likely memory is in an
> inconsistent state, so we don't want to try to recover.

This over-used argument about "memory likely is in an inconsistent state
so-it-is-no-hope" surprises me every time I see it.

Memory is *likely* in an incosistent state, and even if it actually is,
why shouldn't we *try* to do something useful before throwing the whole
thing into a black hole? You may want to log something helpful for
diagnosing the problem (think on an IDE that implements a REPL: knowing
which code broke the compiler is a very interesting piece of
information) or even you may report the problem and try to keep going:
if the process is really trashed, it will die anyway or it will be
killed by the operator (there are scenarios where this is a very
reasonable policy).

Besides, in my experience all LLVM asserts I see are Type mismatches for
instructions and similar cases, i.e., errors about my compiler producing
wrong LLVM "code" through the API, plus some occasional bug on LLVM,
sometimes about one layer passing the wrong thing to the next layer,
sometimes the bug being the existence of the assert check itself.

And finally, as Aaron points out, a robust library reports failures, but
shouldn't kill the process.

-- 
Óscar