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.
Paths
| Differential D146041
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
Unit TestsFailed Event TimelineHerald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptMar 14 2023, 6:25 AM Comment Actions 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 Comment Actions 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).
Comment Actions Ah, here it is: https://llvm.org/docs/CodingStandards.html#error-and-warning-messages Seems to back you up. Comment Actions 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. Comment Actions
Is the title and description appropriate now? Comment Actions
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 ! Comment Actions
This was one of the issues for Outreachy '23, and I asked my outreachy mentor to work on this issue. I'll run ninja check-all, before pushing the next commit for revision. Comment Actions
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. Comment Actions
Thanks for the info @DavidSpickett !! Comment Actions
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.
Comment Actions 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).
Comment Actions 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 . Comment Actions 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?
Revision Contents
Diff 505071 clang/include/clang/Basic/DiagnosticCommonKinds.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaDeclAttr.cpp
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
clang/test/CXX/drs/dr16xx.cpp
clang/test/Lexer/SourceLocationsOverflow.c
clang/test/SemaTemplate/temp_arg_nontype_cxx20.cpp
clang/unittests/Format/FormatTest.cpp
clang/www/demo/index.cgi
lldb/examples/synthetic/libcxx.py
llvm/include/llvm/CodeGen/MachinePassManager.h
llvm/tools/bugpoint/ExecutionDriver.cpp
llvm/tools/bugpoint/ExtractFunction.cpp
llvm/utils/check-each-file
polly/lib/External/isl/imath/tests/test.sh
|
I think we could drop the "unsupported: " here too. (We're allowed to have implementation limits; this isn't a conformance issue.)