Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[#4365] Do not allow --Wdisable or --Wwarn to demote errors. Allow --Winfo=diagnostic to work for diagnostics that can be both warnings and errors. #4366

Merged
merged 4 commits into from
Feb 7, 2024

Conversation

kfcripps
Copy link
Contributor

@kfcripps kfcripps commented Jan 26, 2024

p4test testdata/p4_16_errors/accept_e.p4:

testdata/p4_16_errors/accept_e.p4(18): [--Werror=invalid] error: Invalid parser state: accept should not be implemented, it is built-in
    state accept { // reserved name
          ^^^^^^
testdata/p4_16_errors/accept_e.p4(16): [--Werror=invalid] error: Parser parser p has no 'start' state
parser p()
       ^
p4test testdata/p4_16_errors/accept_e.p4  --Wwarn=invalid:

testdata/p4_16_errors/accept_e.p4(18): [--Werror=invalid] error: Invalid parser state: accept should not be implemented, it is built-in
    state accept { // reserved name
          ^^^^^^
testdata/p4_16_errors/accept_e.p4(16): [--Werror=invalid] error: Parser parser p has no 'start' state
parser p()
       ^
p4test testdata/p4_16_errors/accept_e.p4  --Wdisable=invalid:

testdata/p4_16_errors/accept_e.p4(18): [--Werror=invalid] error: Invalid parser state: accept should not be implemented, it is built-in
    state accept { // reserved name
          ^^^^^^
testdata/p4_16_errors/accept_e.p4(16): [--Werror=invalid] error: Parser parser p has no 'start' state
parser p()
       ^
p4test testdata/p4_16_errors/accept_e.p4  --Winfo=invalid
testdata/p4_16_errors/accept_e.p4(18): [--Werror=invalid] error: Invalid parser state: accept should not be implemented, it is built-in
    state accept { // reserved name
          ^^^^^^
testdata/p4_16_errors/accept_e.p4(16): [--Werror=invalid] error: Parser parser p has no 'start' state
parser p()
       ^

@vlstill
Copy link
Contributor

vlstill commented Jan 26, 2024

(I've restarted a failed test-p4c job as it looked like a transient failure)

@kfcripps kfcripps changed the title [#4365] Do not allow --Wdisable to disable errors. [#4365] Do not allow --Wdisable or --Wwarn to demote errors. Allow --Winfo=diagnostic to work for diagnostics that can be both warnings and errors. Feb 4, 2024
@kfcripps
Copy link
Contributor Author

kfcripps commented Feb 4, 2024

I went with the second approach mentioned in #4365 (comment) (and therefore reverted #4197).

@dmatousek @vlstill @ajwalton Ready for review.

@kfcripps kfcripps marked this pull request as ready for review February 4, 2024 22:20
@kfcripps
Copy link
Contributor Author

kfcripps commented Feb 5, 2024

Updated the PR based on feedback in #4365 (comment). New output for e.g. p4test testdata/p4_16_errors/accept_e.p4 --Wdisable=type-error, p4test testdata/p4_16_errors/accept_e.p4 --Wwarn=type-error, p4test testdata/p4_16_errors/accept_e.p4 --Winfo=type-error:

[--Werror=invalid] error: Error type-error cannot be demoted.

Copy link
Collaborator

@fruffy fruffy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do not have a strong opinion on this topic but this seems like a good change to me.

if (pair.first < ErrorType::ERR_MAX)
error = true;
else
otherDiagnostic = true;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just return false here? Once otherDiagnostic is set the result is always false.

bool otherDiagnostic = false;
for (const auto &pair : errorCatalog) {
if (pair.second == name) {
if (pair.first < ErrorType::ERR_MAX)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a nit, maybe also check that the value is within both ends of the error range.

@@ -231,6 +231,7 @@ class ErrorReporter {
/// @return the action to take for the given diagnostic, falling back to the
/// default action if it wasn't overridden via the command line or a pragma.
DiagnosticAction getDiagnosticAction(cstring diagnostic, DiagnosticAction defaultAction) {
if (defaultAction == DiagnosticAction::Error) return defaultAction;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a comment here that actions for errors can never be overridden. Maybe even return DiagnosticAction::Error always?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a ingnored typo in the comment below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe even return DiagnosticAction::Error always?

Do you mean like this:

if (defaultAction == DiagnosticAction::Error) return DiagnosticAction::Error;

What is the benefit?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it would make it explicit and one could not circumvent this invariant by passing in another default action. But if someone goes through the trouble of doing that they may have a reason.

// (e.g. "invalid" -> both ERR_INVALID and WARN_INVALID).
bool error = false;
bool otherDiagnostic = false;
for (const auto &pair : errorCatalog) {
Copy link
Collaborator

@fruffy fruffy Feb 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

~~Also I feel like the error catalogue should be a map? But this can be done some other time. ~~

Nevermind, it is. But it is not 2-dimensional.

@kfcripps
Copy link
Contributor Author

kfcripps commented Feb 7, 2024

@fruffy I have implemented several of your suggestions. Please let me know if the changes look ok and I will rebase & merge this.

@kfcripps kfcripps requested a review from fruffy February 7, 2024 01:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants