Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Support multiple severity levels for diags from a single checker

Aperta
#4,643 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

discussion :bulb:

I have a checker that flags differences in parameter type declaration spelling between the prototype and definition for C functions. Some differences (for example, inconsistent use of 'const' qualifier) are purely questions of STYLE. But it can be argued that some (for example, inconsistent use of 'restrict' qualifier) have real risk, even though the difference in declaration spelling is meaningless to the compiler. So, I'd like to set the severity for some of the diagnostics differently than for the purely-STYLE findings.

As things stand, with CodeChecker settings, I don't see a way for distinct diagnostics from a single checker to have different severity levels. I think it might be possible to do something like this with regular expressions in the codechecker config, though. Perhaps, instead of

"mychecker": [ "doc_url:https://blah-blah-blah/blah-blah", "severity:STYLE" ],

we might have:

"mychecker": [ "doc_url:https://blah-blah-blah/blah-blah", "conditional-severity": [ "match-regex:.*restrict.*", "severity:LOW" ], "severity:STYLE" ],

Not sure what would make the most sense for the config parser, as this format looks like JSON at the top, but values in the JSON look like they are further broken into key/value pairs with some additional custom syntax expectations...

The only other alternative is for me to break the checker into multiple checkers with different severity levels, which costs extra runtime, and also can generate redundant diagnostics (consider a single declaration where both 'const' and 'restrict' are used inconsistently between prototype and definition, for example -- a single checker can emit one diagnostic and one fixit covering both conditions, but multiple checkers cannot). Breaking up the checker also increases code complexity and/or maintenance risk for the checker implementation.

I've had similar cases before that forced me to break checkers up into multiple checkers. Since this came up for me a second time, I thought I might ask...

Lingua principale
Python
Stelle
2.6k
Fork
494
Merge medio
3g 1h
PR unite (30g)
20

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Ericsson/codechecker

Tutte le issue di Ericsson/codechecker

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.