search

chapel-lang / chapel

a Productive Parallel Programming Language
https://chapel-lang.org
Other
1.79k stars 421 forks source link

Compiler LLVM fatal errors aren't very helpful without CHPL_DEVELOPER right now #25203

Open lydia-duncan opened 5 months ago

lydia-duncan commented 5 months ago

We had a nightly test failure trigger an internal compiler here from this line: https://github.com/chapel-lang/chapel/blob/main/compiler/llvm/clangUtil.cpp#L2685

However, because nightly testing doesn't use CHPL_DEVELOPER, all we got out of it was:

> internal error: LLV-CLA-TIL-2685 chpl version 2.1.0 pre-release (6b96fedd81)
>
> Internal errors indicate a bug in the Chapel compiler,
> and we're sorry for the hassle.  We would appreciate your reporting this bug --
> please see https://chapel-lang.org/bugs.html for instructions.
>

Given that it looks like it could be any LLVM failure mode that triggers this internal error, I don't think the set up is currently very useful. If CHPL_DEVELOPER were set, it'd give the reason for the crash, but because it wasn't, we don't get any information out of it.

It's still probably not the user's fault in the case where a user in the field might encounter it, so we should still ask them to report it to us rather than trying to fix the issue themselves, but it seems like it would be more helpful to display the actual error message it got as well, so that they can pass it on to us in case we can't reproduce it with just their code.

Spitballing, I'd maybe do something like:

USR_NOTE("The following error is an internal error, indicating a bug in the Chapel compiler,\nand we're "
        "sorry for the hassle.  We would appreciate your reporting this bug "
        "--\nplease see https://chapel-lang.org/bugs.html for instructions.\n");
USR_FATAL("llvm fatal error: %s", reason);

Though depending on the error message, I could see the "please report" message getting mentally skipped over by the user. Thoughts?

bradcray commented 5 months ago

I'm not sure I think this case is inherently more worthy of a more detailed/verbose error message than a normal internal error given that the user doesn't seem likely to be able to do anything with the information. But in either case, I could imagine suggesting the user re-compile with --devel and share that information with us if they're motivated to do so.

Not immediately related to this request, but the retention of the linefeed after Chapel compiler, reminds me of https://github.com/chapel-lang/chapel/issues/22892, which still grates on me each time I get an internal error.