Python: trailing comma in a PEP 695 type parameter list causes a parse error
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 88/100
Research direction
Start in tsg-python/tsp/grammar.js at the type_parameters rule, then compare its comma handling with the linked CPython grammar. Done means the Python extractor accepts trailing commas in PEP 695 type parameter lists for class, def, and type statements, including the formatted example shown.
Written by the indexing model from the issue text.
Description
Description of the issue
The Python extractor (CodeQL CLI 2.27.1) fails to parse a trailing comma after the last type parameter, and the file is dropped from analysis. This applies to class, def and type statements. ruff format and Black add this comma whenever they split a long type parameter list, so formatted code runs into it.
class A[
T: int,
U: str, # Syntax Error here
]:
pass
type_parameters in tsg-python/tsp/grammar.js has no optional trailing comma, while CPython's grammar does (type_param_seq: ','.type_param+ [',']). Adding it fixes the error:
type_parameters: $ => seq(
'[',
commaSep1(field('type_parameter', $._type_parameter)),
+ optional(','),
']'
),
- Dominant language
- CodeQL
- Stars
- 10.1k
- Forks
- 2.1k
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 147
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/codeql
-
false-positive javascript
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
github/codeql#22632 · 1 comment ·
Maintainers usually reply within 1 day
-
C#: cs/simplifiable-boolean-expression false positive on Nullable<bool> compared with a literalPossibly taken @michaelnebel claimed this 3 days ago. OpenC#
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
github/codeql#22556 · 2 comments · 1 assignee ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
github/codeql#21637 · 2 comments ·
Maintainers usually reply within 1 day
-
false-positive
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
github/codeql#21076 · 3 comments · 3 reactions ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
github/codeql#22702 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
self-host checker: E021 bound check reads an untyped literal at i32, not the type the call bindsOpen
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
JakeChampion/lang#11055 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
checker: module referenced only inside a `sql db { ... }` block is reported as an unused importOpen
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day