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