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

[Thomas Goodfellow via llvm-dev]

Having re-read your first mail with better attention, you're quite
correct: MCContext::reportError() does give a good error pathway from
llvm-mc (no .o emitted, exit code == 1), and that's the answer to my
problem, i.e. something like:

if(warning) {
  auto SM(CTX.getSourceManager());
  if(SM) {
    SM->PrintMessage(MI.getLoc(), SourceMgr::DK_Warning, msg);
    return;
  }
  // without SrcMgr least-worst approach is promoting warning to error
}
CTX.reportError(MI.getLoc(), msg);

Having a similar MCContext::reportWarning() API to conceal the SrcMgr
plumbing would be nice.

Thanks again for your help!

On Thu, 6 Feb 2020 at 00:23, Reid Kleckner <rnk at google.com> wrote:
>
> 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