Add Python version checks to native parser

[KevinRK29]

The native parser (rust based) previously accepted newer Python syntax without checking the configured target Python version, whereas the legacy parser (fastparse) would report when a feature isn't available on the target (although those would be blocking errors). This PR adds those compatibility checks to the native parser so that it produces a non blocking error.

The feature gates added are:

• improved type parameter syntax for Python 3.12
• type parameter defaults for Python 3.13
• type alias statements for Python 3.12
• exception groups (except*) for Python 3.11
• star unpack for Python 3.11
• t-strings for Python 3.14

I've also moved the tests that would now introduce a python version check error to it's own test file so that it gets the correct Python versoin

In a later PR, I will be adding support for checking this feature since it requires modifying the rust parser a bit:

• Parentheses optional for multiple exception types in except

[JukkaL]

Also these features may need checks:

• Star unpack (tuple[*Ts]) introduced in 3.11
• Parentheses optional for multiple exception types in except

The latter may require changes to the parser. If that's the case, we can leave it until later.

[JukkaL]

Maybe call this feature "Improved type parameter syntax"? You'd need to use singular "is" instead of "are" in the error message in this case, or leave out the verb altogether.

[JukkaL]

Similar to above (name of feature).

[JukkaL]

I think T-strings are a bit special since they need to new stdlib type, and it's not defined on older versions. This means that we probably shouldn't allow them in stubs either unless targeting 3.14 or later. Also this is important to test using real stubs (pythoneval.test) to ensure the missing type doesn't cause issues.

[KevinRK29]

@JukkaL

So looking at this further, currently the stance is that version check errors are non blocking, so they have blocker = false, which lets type checking continue against an AST that's been parsed for a feature the target Python doesn't support? Currently we reset the is_star from True to False after we encounter it with the version issue, but that would cause a divergence in the AST. This would also affect what the reveal_type would show.

If we keep it as non blocking but don't reset the is_star, it would cause a mypy crash with INTERNAL_ERROR because typeshed gates that class for the specific version and would complain that the symbol isn't in the builtins symbol table.

The other alernative is to keep make it a blocking error just for this case, however im not sure if that would be inconsistent since it may cause confusion for the user on whether version checks do block or not? Or we follow fastparse and always block.

[KevinRK29]

regarding this feature:

• Parentheses optional for multiple exception types in except

I believe i would need to update the rust side to record whether the source used parenthesis and then have the python read it and do the version check, so it might be better to do it in a later pr

[JukkaL]

I think it's fine to just assign False to the is_star flag for now, since that feature isn't available on older Python versions, and it's more important to not generate a blocking error than to provide the same AST we'd generate on a newer version.

[JukkaL]

You can move these tests to a new native-parser-python311.test file and register it in test_nativeparse.py so that you'll get the correct Python version set (and similarly for test cases the require 3.12, etc.).

[JukkaL]

Add reveal_type(g) and check what happens if we call g. It's okay if this behaves inconsistently, as long as it doesn't crash and doesn't do anything very strange.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[KevinRK29]

sounds good then, i've addressed the comments!

[JukkaL]

Thanks, looks good! One more thing -- can you add a pythoneval test that uses the new generics syntax in a .pyi file while targeting 3.10? The test case can be added in a follow-up PR if you prefer.