llvm dev - Feb 2020 - Reporting source errors from MCCodeEmitter::encodeInstruction() ?

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

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/20200204/6db50f84/attachment.html>

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>

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