Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support multiple severity levels for diags from a single checker

Abierto
  • ¿Algo no está bien?
#4,643 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
8/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
c, python
Área
tooling

Línea de trabajo

This is a design question, not a patch. The issue asks how a checker's per-checker config (the doc_url and severity entries) could assign different severities to diagnostics from one checker, based on a regex match on the message. Before any code, a maintainer needs to pick the config syntax and how it is parsed; the issue itself leaves that open. Starting point: the checker configuration and severity handling in the CodeChecker repository. Done means an agreed format and a decision on whether the feature belongs in CodeChecker at all.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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...

Lenguaje dominante
Python
Estrellas
2.6k
Forks
494
Merge medio
3 d 1 h
PR fusionados (30 d)
20

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Ericsson/codechecker

Todos los issues de Ericsson/codechecker

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.