[llvm-dev] Reporting source errors from MCCodeEmitter::encodeInstruction() ?

[Reid Kleckner via llvm-dev]

Well, MCContext::reportError does track errors, so llvm-mc could check for
errors at the end.

On Wed, Feb 5, 2020 at 3:59 AM Thomas Goodfellow <
thomas.goodfellow at gmail.com> wrote:

> Thanks - having looked further it doesn't seem SourceManager does
> anything around PrintMessage() beyond emitting nice contextual error
> messages. Here's an invocation from AsmParser::printError():
>
>    HadError = true;
>    printMessage(L, SourceMgr::DK_Error, Msg, Range);
>    printMacroInstantiations();
>    return true;
>
> So seemingly the error tracking is down to the invoker, although it
> *might* be nice if counting errors and warnings was part of the
> SourceManager functionality. Somewhat surprisingly it seems that
> frontends such as Clang don't use this mechanism at all? (weak
> evidence for this assertion being that clang only uses
> setDiagHandler() for the case of inline assembly, and a breakpoint on
> PrintMessage() isn't hit for C/C++ parse errors)
>
> That leaves the question of how errors are most politely handled from
> the level of MCCodeEmitter::encode/emitInstruction, i.e. ideally
> allowing evaluation to proceed for subsequent instructions so that all
> errors get presented at once but then handling it as an overall
> failure.
>
> On Wed, 5 Feb 2020 at 00:36, Reid Kleckner <rnk at google.com> wrote:
> >
> > I was going to say use MCContext::reportError, but that mainly calls
> SourceManager::PrintMessage. Does that not prevent clang from emitting a .o
> file? That seems like a bug if so.
> >
> > On Tue, Feb 4, 2020 at 2:59 PM Thomas Goodfellow via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>
> >> [apologies for this duplicate post: originally sent to lldb-dev by not
> >> paying attention to the address auto-completion]
> >>
> >> We have a backend for a target that at present only detects some
> >> assembler errors when emitting instructions (basically because the
> >> platform has configurable properties with dependencies between
> >> instructions and it was easier to check for their interaction late
> >> than try to detect them earlier, e.g. through custom encoder methods
> >> and tablegen). Emitting diagnostics through
> >> SourceManager::PrintMessage() "works" in the limited sense of
> >> communicating the problem to a human, however it doesn't prevent
> >> generation of an incorrect output file or change the process exit
> >> code.
> >>
> >> We'd prefer not to resort to report_fatal_error() since that isn't a
> >> polite way to diagnose problems in the source.
> >>
> >> Is there a sensible way to properly signal a source error from the
> >> level of encodeInstruction()? Or is it expected that all such errors
> >> are reported earlier?
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200205/e45cdb5b/attachment.html>