[RFC] report_fatal_error and the default value of GenCrashDialog

[jayfoad]

@mehdi_amini

@asb

Maybe we’re talking past each other here, but I think almost every instance of report_fatal_error is unfortunate

Maybe you’re looking only at the LLVM backend, but I would hope that none of the instance of report_fatal_error in MLIR for example is subject to be trigger on user-input (they are meant to fire to catch issue for the people “assembling the compiler” and not for people “using the compiler”), and if they trigger: it is a bug!

We’re talking about the default here I believe, and whenever I’m using report_fatal_error, I really mean that this “should not happen” (it’s stronger than assertions…) and to me this is just the better default behavior: this cannot be a blessed way to do error handling, regardless of the history in LLVM backends…

If you work on some piece of LLVM that should have better error reporting, I can only encourage you to refactor it as such, or be explicit about the non-standard intent.

Reviving this thread since it came up again in [Support] report_fatal_error: Do not generate crash backtrace by default by optimisan · Pull Request #128495 · llvm/llvm-project · GitHub.

I really think the LLVM usage of report_fatal_error is far more standard, just based on the name of the function: it clearly means report an error to the user and terminate the process.

Using it for “should not happen” is the non-standard intent. That should be some form of assertion. I don’t understand what you mean by “it’s stronger than assertions” – surely that can be handled by having different flavours of assertion function: assert_with_diagnostic or assert_with_backtrace or whatever.

I’m strongly in favour of #128495 or something like it.