github / github/codeql

Consistently use fully qualified type names in Java external flow method signatures

Aberta
#12,290 1 comentário 0 reações 0 responsáveis Ver no GitHub
enhancement
Linguagem predominante
CodeQL
Estrelas
10.1k
Forks
2.1k
Merge médio
2d 15h
PRs com merge (30d)
141

Descrição

The data flows described by the YAML files in https://github.com/github/codeql/tree/main/java/ql/lib/ext optionally contain method signatures, when the data only applies to specific overloads of the method by the given name. Typically these signatures have been specified using unqualified type references, as in the following examples: https://github.com/github/codeql/blob/748387a69f68ea6197f207342189a4ede7425538/java/ql/lib/ext/javax.json.model.yml#L6-L7

There are however also many cases, where qualified type names are used. Here are a few examples of this kind: https://github.com/github/codeql/blob/748387a69f68ea6197f207342189a4ede7425538/java/ql/lib/ext/org.springframework.util.model.yml#L95-L97

For the generated data the type references appear to consistently be unqualified.

While I don't know how CodeQL currently consumes these models, I would have expected it to be an advantage to always have fully qualified type references, to be able to unambiguously resolve the type references and in the end the method. Theoretically it would for instance be possible that a given library adds a new overload, where a parameter has the same unqualified name as another overload and that the CodeQL model could then not be resolved unambiguously anymore.

While all these models could probably be processed in an automated manner to consistently use qualified type names, it would probably make sense to introduce checks to ensure that no future models start using unqualified type names again.

Guia de contribuição

Abrir o guia de contribuição

Avaliação

Esta issue ainda não foi avaliada.

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.