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

[David Blaikie]

On Fri, Aug 2, 2013 at 3:00 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>> 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!");

Presumably this should only fire for code that doesn't pass the
verifier & no program using the LLVM APIs should generate such a
program (if they do, that's a programming error on their part - the
assertion is there to help them fix the bug, LLVM will not be
resilient to such errors). User-provided IR goes through the verifier
& gets nice pretty error messages, etc, rather than assertion
failures.

>
> 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