(original) (raw)

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@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@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev