Details
- Reviewers
aaron.ballman MaskRay - Group Reviewers
Restricted Project - Commits
- rGb4e0589b2cd9: [clang][Verify] Show prefix in -verify error messages
Diff Detail
Event Timeline
I'm not opposed but I am wondering what the need is for this? (It'd be good to capture that information in the patch summary as well.) Some examples showing where this helps to correct the issue would be useful.
When passing a different prefix via -verify=foo, the error messages now say "error: 'foo-error' diagnostics seen but not expected", etc.
I'm often working in test files where two different prefixes are used and I'm always confused about which one of the two the error messages are talking about.
What I'm confused by is that we list the line numbers of the failures, so the prefix only seems like it's helpful in a case where two prefixes use the same message and the same severity on the same line. e.g., // foo-error {{whatever}} bar-error {{whatever}}. In the other cases, either the line number is different, or the severity is different, or the message is different which I thought was giving sufficient context.
This is also reported as being on line 4:
// RUN: %clang_cc1 -fsyntax-only -fdiagnostics-print-source-range-info -verify=bar %s 2>&1 static_assert(true); // foo \ // bar-error {{failed}}
which is also the case if line 4 contained another foo-error {{failed}} which didn't trigger, leaving developers wondering which one it is.
Okay, we do that often enough in our tests (along with two diagnostics on the same line directly) that this seems pretty reasonable to me.
Can you add some test coverage where the prefix is not the default expected?
The change looks great: (from error: 'error' diagnostics seen but not expected: to error: 'expected-error' diagnostics seen but not expected).
When I read Clang tests, I was confused by what error meant. I eventually figured out -verify is special. The new diagnostic is clearer and more helpful.
clang/lib/Frontend/VerifyDiagnosticConsumer.cpp | ||
---|---|---|
881 | The variables are immediately used. I think in this case our convention is omit the blank line (and in general I think we omit blank lines for many more cases, compared to some other projects (GNU, Linux kernel, etc)). | |
clang/test/Frontend/verify.c | ||
159 | This may need a comment explaining that this is not recognized as a directive. |
clang/test/Frontend/verify.c | ||
---|---|---|
159 | Not sure I follow, what isn't being recognized as a directive? |
The variables are immediately used. I think in this case our convention is omit the blank line (and in general I think we omit blank lines for many more cases, compared to some other projects (GNU, Linux kernel, etc)).