[clang] [llvm] [mlir] [ErrorHandling] Add reportFatalInternalError + reportFatalUsageError (NFC) (PR #138251)
Mehdi Amini via cfe-commits
cfe-commits at lists.llvm.org
Fri May 2 05:40:05 PDT 2025
================
@@ -59,22 +59,41 @@ namespace llvm {
~ScopedFatalErrorHandler() { remove_fatal_error_handler(); }
};
-/// Reports a serious error, calling any installed error handler. These
-/// functions are intended to be used for error conditions which are outside
-/// the control of the compiler (I/O errors, invalid user input, etc.)
-///
-/// If no error handler is installed the default is to print the message to
-/// standard error, followed by a newline.
-/// After the error handler is called this function will call abort(), it
-/// does not return.
-/// NOTE: The std::string variant was removed to avoid a <string> dependency.
+/// @deprecated Use reportFatalInternalError() or reportFatalUsageError()
+/// instead.
[[noreturn]] void report_fatal_error(const char *reason,
bool gen_crash_diag = true);
[[noreturn]] void report_fatal_error(StringRef reason,
bool gen_crash_diag = true);
[[noreturn]] void report_fatal_error(const Twine &reason,
bool gen_crash_diag = true);
+/// Report a fatal error that likely indicates a bug in LLVM. It serves a
+/// similar purpose as an assertion, but is always enabled, regardless of the
+/// value of NDEBUG.
+///
+/// This will call installed error handlers (or print the message by default)
+/// and then abort. This will produce a crash trace and *will* ask users to
+/// report an LLVM bug.
+[[noreturn]] void reportFatalInternalError(const char *reason);
+[[noreturn]] void reportFatalInternalError(StringRef reason);
+[[noreturn]] void reportFatalInternalError(const Twine &reason);
+
+/// Report a fatal error that does not indicate a bug in LLVM, in contexts
+/// where a more sophisticated error reporting mechanism (such as Error/Expected
+/// or DiagnosticInfo) is not supported.
+///
+/// Examples where this function should be used include invalid inputs or
+/// options, but also environment error conditions outside LLVM's control.
+/// It should also be used for known unsupported/unimplemented functionality.
----------------
joker-eph wrote:
> If you can report the error via Error return or similar, you would of course do that, but there are many places that don't support it.
This whole sentence is weird: we are developing the project, there is **nowhere** that we **cannot** do it: I have yet to see one component in the compiler that couldn't do this really. It's only a choice of us to not support it.
The current phrasing isn't satisfactory because it does not capture the nuance and makes it seem it's just OK to use.
The paragraph "Examples where this function should be used": I'd say it **should** never be user, instead we may say it "might be used when propagating an error would require a large refactoring that is deemed impractical at the moment" for example.
https://github.com/llvm/llvm-project/pull/138251
More information about the cfe-commits
mailing list