[lld] r187670 - Use report_fatal_error() instead of llvm_unreachable() to show broken input file error.

Rafael EspĂ­ndola rafael.espindola at gmail.com
Fri Aug 2 15:00:54 PDT 2013


> It shouldn't have to - assert liberally isn't about error reporting,
> it's about failing early when LLVM enters into an
> unexpected/unplanned/undesigned state so we can fix bugs more easily.
>
> Those are distinct from error cases based on external inputs that can
> actually be broken/invalid/etc - those codepaths should never be
> asserts & should go through some appropriate error reporting
> mechanism.

Broken machine generated files are a gray area. I think we all agree
that we should not show a "assertion failure at line blah blah" to an
end user, but fatal errors actually make it easier to say "found a
broken symbol table in a member of an archive" or failing that just a
"unexpected error while processing member foo.o of archive foo.a".

We do use asserts when reading IR files, for example, check BitcodeReader.cpp:

assert(Ty == V->getType() && "Type mismatch in constant table!");

I find errer_code awesome for cases where what looks like an error to
the callee, is not an error for the caller (trying to opening a file
that may or may not exist being the canonical example). Other than the
above and the performance cost, another issue I have with it for known
hard errors is that it is really easy to ignore. Look at
RelocVisitor.h. The interfaces there don't propagate errors out. If a
file does have a broken relocation, we can just produce a broken
result, which is even worse that an incomprehensible assert.

Cheers,
Rafael



More information about the llvm-commits mailing list