// map from errorCode to ErrorSig
std::map<int, cstring> ErrorCatalog::errorCatalog = {
// Errors
{ErrorType::LEGACY_ERROR, "legacy"},
{ErrorType::ERR_UNKNOWN, "unknown"},
{ErrorType::ERR_UNSUPPORTED, "unsupported"},
{ErrorType::ERR_UNEXPECTED, "unexpected"},
{ErrorType::ERR_EXPECTED, "expected"},
{ErrorType::ERR_NOT_FOUND, "not-found"},
{ErrorType::ERR_INVALID, "invalid"},
{ErrorType::ERR_EXPRESSION, "expr"},
{ErrorType::ERR_OVERLIMIT, "overlimit"},
{ErrorType::ERR_INSUFFICIENT, "insufficient"},
{ErrorType::ERR_UNINITIALIZED, "uninitialized"},
{ErrorType::ERR_TYPE_ERROR, "type-error"},
{ErrorType::ERR_UNSUPPORTED_ON_TARGET, "target-error"},
{ErrorType::ERR_DUPLICATE, "duplicate"},
{ErrorType::ERR_IO, "I/O error"},
{ErrorType::ERR_MODEL, "Target model error"},
{ErrorType::ERR_RESERVED, "reserved"},
// Warnings
{ErrorType::LEGACY_WARNING, "legacy"},
{ErrorType::WARN_FAILED, "failed"},
{ErrorType::WARN_UNKNOWN, "unknown"},
{ErrorType::WARN_INVALID, "invalid"},
{ErrorType::WARN_UNSUPPORTED, "unsupported"},
{ErrorType::WARN_DEPRECATED, "deprecated"},
{ErrorType::WARN_UNINITIALIZED, "uninitialized"},
{ErrorType::WARN_UNUSED, "unused"},
{ErrorType::WARN_MISSING, "missing"},
{ErrorType::WARN_ORDERING, "ordering"},
{ErrorType::WARN_MISMATCH, "mismatch"},
{ErrorType::WARN_OVERFLOW, "overflow"},
{ErrorType::WARN_IGNORE_PROPERTY, "ignore-prop"},
{ErrorType::WARN_TYPE_INFERENCE, "type-inference"},
{ErrorType::WARN_PARSER_TRANSITION, "parser-transition"},
{ErrorType::WARN_UNREACHABLE, "parser-transition"},
{ErrorType::WARN_SHADOWING, "shadow"},
{ErrorType::WARN_UNINITIALIZED_USE, "uninitialized_use"},
{ErrorType::WARN_UNINITIALIZED_OUT_PARAM, "uninitialized_out_param"},
{ErrorType::WARN_IGNORE, "ignore"},
{ErrorType::WARN_INVALID_HEADER, "invalid_header"},
{ErrorType::WARN_DUPLICATE_PRIORITIES, "duplicate_priorities"},
{ErrorType::WARN_ENTRIES_OUT_OF_ORDER, "entries_out_of_priority_order"},
My opinion is that allowing errors to be disabled is a bad idea, as disabling some error could result in unexpected behavior, but maybe there was a reason to allow this...
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): [--Wwarn=invalid] warning: Invalid parser state: accept should not be implemented, it is built-in
state accept { // reserved name
^^^^^^
testdata/p4_16_errors/accept_e.p4(16): [--Wwarn=invalid] warning: Parser parser p has no 'start' state
parser p()
^
testdata/p4_16_errors/accept_e.p4(18): [--Werror=duplicate] error: accept: Duplicates declaration accept
state accept { // reserved name
^^^^^^
p4test testdata/p4_16_errors/accept_e.p4 --Wdisable=invalid:
testdata/p4_16_errors/accept_e.p4(18): [--Werror=duplicate] error: accept: Duplicates declaration accept
state accept { // reserved name
^^^^^^
p4test testdata/p4_16_errors/accept_e.p4 --Winfo=invalid:
[--Werror=invalid] error: Error invalid cannot be demoted
Some warnings and errors have the same name, for example
ERR_INVALIDandWARN_INVALID:As a result, for example,
--Wdisable=invalidwill disable errors of typeERR_INVALID. Is this expected?I have the same question about the
--Wwarnoption.Also, the
--Winfooption seems to explicitly disallowdiagnostics that are both errors and warnings, which is inconsistent with how--Wwarnand--Wdisabletreats suchdiagnostics.My opinion is that allowing errors to be disabled is a bad idea, as disabling some error could result in unexpected behavior, but maybe there was a reason to allow this...
A few examples: