This is an archive of the discontinued LLVM Phabricator instance.

Fix weirdly apologetic diagnostic messages
Needs ReviewPublic

Authored by AryanGodara on Mar 14 2023, 6:25 AM.

Details

Summary

Signed-off-by: aryan <aryangodara03@gmail.com>

Resolves https://github.com/llvm/llvm-project/issues/61256

The aim of the patch is to make the error logs less verbose and apologetic, and stick mainly to explain the issue in minimum words.

Diff Detail

Event Timeline

AryanGodara created this revision.Mar 14 2023, 6:25 AM
Herald added a reviewer: NoQ. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
AryanGodara requested review of this revision.Mar 14 2023, 6:25 AM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptMar 14 2023, 6:25 AM

You should look into the title and description of the commit: https://cbea.ms/git-commit/

AryanGodara retitled this revision from initial commit to Fix weirdly apologetic diagnostic messages.Mar 14 2023, 6:51 AM
AryanGodara edited the summary of this revision. (Show Details)

Is there some standard for writing warning messages? For llvm that is, it would be worth looking through the getting started guides to see. I think the majority of warnings are "formal" in that sense so this seems fine.

Personally I agree with making the warnings more succinct but aside from that I don't see the need to change comments or testing scripts.

You may consider splitting this change into 2. One that only changes warnings and errors (a less controversial change) and the rest (that is up to the reviewers of each bit).

clang/test/SemaTemplate/temp_arg_nontype_cxx20.cpp
51

Please find out what the {{sorry}} here was for. Did someone literally write it as an apology, or is it indicating some warning that should be emitted here, if the FIXME is fixed?

You could git blame this file and find the commit that introduced it, as a starting point.

polly/lib/External/isl/imath/tests/test.sh
12

Given that this is a developer facing script, I think the "did you build it" is in fact quite useful here. Perhaps it could say:
"The imath test driver 'imtest' was not found. Did you build it? It is required for running the tests."

I'm not certain if it's bad to say 'sorry', IMHO it's fine?

Anyway, you can't just simply delete those words (in diagnostic messages and regression tests), that doesn't work. To verify the patch is good, you can run ninja check-all to make sure the testsuite passes.

emaste added a subscriber: emaste.Mar 14 2023, 9:43 AM

You should look into the title and description of the commit: https://cbea.ms/git-commit/

Is the title and description appropriate now?
I can add more details to the description, as required

Is there some standard for writing warning messages? For llvm that is, it would be worth looking through the getting started guides to see. I think the majority of warnings are "formal" in that sense so this seems fine.

Personally I agree with making the warnings more succinct but aside from that I don't see the need to change comments or testing scripts.

You may consider splitting this change into 2. One that only changes warnings and errors (a less controversial change) and the rest (that is up to the reviewers of each bit).

I will do go through the changes I made, and first make sure to change only warnings and errors.

Since this is my first commit to such a large repository(and project), can you please guide me with this @DavidSpickett !

I'm not certain if it's bad to say 'sorry', IMHO it's fine?

Anyway, you can't just simply delete those words (in diagnostic messages and regression tests), that doesn't work. To verify the patch is good, you can run ninja check-all to make sure the testsuite passes.

This was one of the issues for Outreachy '23, and I asked my outreachy mentor to work on this issue.
I'm looking for any help to make the patch more meaningful, and get guidance along the way.

I'll run ninja check-all, before pushing the next commit for revision.

Since this is my first commit to such a large repository(and project), can you please guide me with this @DavidSpickett !

Sure, you'll want to make a commit that only has changes to warnings and errors. You can split up this one to do that, see part "A)" of this answer https://stackoverflow.com/questions/6217156/break-a-previous-commit-into-multiple-commits/6217314#6217314. Then you can update this review with that new commit, change the description/title etc. if needed.

If you get confused with updating the review (happens to me all the time) you can just abandon this (there is an entry in the "Add Action..." menu) and make a new review as you did before.

How to identify what changes should be included? I would ignore comments, shell scripts, FIXMEs, or general test data. If the test is producing a warning and looking for it, clearly it should be changed. If it's just random data it's using to test some function, I wouldn't change it.

Since this is my first commit to such a large repository(and project), can you please guide me with this @DavidSpickett !

Sure, you'll want to make a commit that only has changes to warnings and errors. You can split up this one to do that, see part "A)" of this answer https://stackoverflow.com/questions/6217156/break-a-previous-commit-into-multiple-commits/6217314#6217314. Then you can update this review with that new commit, change the description/title etc. if needed.

If you get confused with updating the review (happens to me all the time) you can just abandon this (there is an entry in the "Add Action..." menu) and make a new review as you did before.

How to identify what changes should be included? I would ignore comments, shell scripts, FIXMEs, or general test data. If the test is producing a warning and looking for it, clearly it should be changed. If it's just random data it's using to test some function, I wouldn't change it.

Thanks for the info @DavidSpickett !!
I will try to split this commit, and update on this asap (Sorry for the late update, I have mid-sem exams going on, I haven't abandoned this issue, still working on it).

I will try to split this commit, and update on this asap (Sorry for the late update, I have mid-sem exams going on, I haven't abandoned this issue, still working on it).

No worries about the speed of updates, it's totally fine for weeks to pass between updates to a patch. We're usually pretty good at asking "is this abandoned" rather than assuming. FWIW, it looks like there's also precommit CI failures related to the changes that should be looked into.

clang/unittests/Format/FormatTest.cpp
11426

These changes don't really do much -- it's a test case, so the wording is not important, but what is important is retaining the string argument that is being dropped. I'd roll back the changes to this file.

rsmith added a subscriber: rsmith.Mar 17 2023, 12:24 PM

I have no strong opinions on the merits of this patch in either direction; I think the "sorry"s in the Sema diagnostics for regrettable non-conformance make Clang marginally friendlier, but they do nothing to actually help people who encounter the diagnostic.

FWIW, the relevant guidance on Clang diagnostics is https://clang.llvm.org/docs/InternalsManual.html#the-format-string, and that would override the LLVM coding guidelines' rules in places where they conflict (though in this case there's no conflict).

clang/include/clang/Basic/DiagnosticCommonKinds.td
338

I think we could drop the "unsupported: " here too. (We're allowed to have implementation limits; this isn't a conformance issue.)

341

Please remove the trailing period while you're fixing the style of this diagnostic.

clang/include/clang/Basic/DiagnosticSemaKinds.td
9669

While we're fixing style: in this file we have "is not yet supported", "is not supported yet", and "is not supported". We should pick one and use it consistently; "is not supported yet" would be my preference.

clang/test/SemaTemplate/temp_arg_nontype_cxx20.cpp
11–12

You should retain a {{...}} here with some text from the diagnostic for -verify to match against. Likewise below.

Hi @AryanGodara , I am an Outreachy applicant. I was also working on this issue and also created a patch for this issue i.e., https://reviews.llvm.org/D146530 . Can we collaborate to solve this issue so that only one patch will be there for a issue as told by @aaron.ballman .

manas added a subscriber: manas.Mar 22 2023, 1:23 PM

Hi, I came across this due to changes in Static Analyzer. One of the changes is not related to the Github issue mentioned above. Maybe we can drop that file?

clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
1214–1215

This is unrelated to the above mentioned issue.