Repository navigation
New parser deviates from old parser in edge cases with function type comments #21948
Description
Activity
I'd like to pick this up — unless you're planning to handle it as part of the native-parser work in #21823, in which case happy to stand aside.
Understanding
With the new parser enabled, a function carrying a function-type comment that disagrees with its actual signature is no longer diagnosed. For the reported one-liner, the old parser flags the nested
def's# type: () -> Nonecomment as mismatching the annotated parameter, while the new parser silently accepts it (false negative). So this is a parser-parity regression in the type-comment validation path, freshly exposed by the parser default flip.Plan
- Add a testdata case (under the check-functions tests, or wherever function-type-comment diagnostics are grouped) that pins the expected error for the reported snippet, including the nested-function case.
- Restore the signature-compatibility check for function type comments in the new parser, so parameter count/type mismatches are diagnosed exactly as the old parser did.
- Run the full test suite plus mypy self-check; if anything interacts with the migration machinery around Make native parser the default #21823 I'll call it out in the PR.
I'm starting now and will open a PR within the next couple of days.
@abhinav-phi Just to save you some time:
- We do not accept LLM generated PRs from new contributors, see https://github.com/python/mypy/blob/master/CONTRIBUTING.md
- Fixing this issue needs good understanding of mypy architecture, so I am not sure it is a good first issue.
- Most of the work for this issue would be done in https://github.com/mypyc/ast_serialize
This is a follow-up for #21823. Most notably we get a false negative in situations like this:
cc @JukkaL