Skip to content

Use AST_SERIALIZE_CACHE_VERSION when natively parsing type strings - #22474

Open
Jahongir-Qurbonov wants to merge 1 commit into
python:masterfrom
Jahongir-Qurbonov:nativeparse-cache-version
Open

Jahongir-Qurbonov wants to merge 1 commit into
python:masterfrom
Jahongir-Qurbonov:nativeparse-cache-version

Conversation

@Jahongir-Qurbonov

Copy link
Copy Markdown
Contributor

#22434 made the native parser pass AST_SERIALIZE_CACHE_VERSION to ast_serialize, but native_parse_type_string() still passes a hardcoded cache_version=5 to ast_serialize.parse_type_string() (the constant is now 7).

The serialized output for type strings happens to be the same for versions 5 and 7 today, so nothing is broken yet, but the next version bump that changes the type encoding would be missed by this call and read_type() would then read data written in an older format. This uses the constant here as well.

native_parse_type_string() still passed a hardcoded cache_version=5 to
ast_serialize.parse_type_string(), while the other parse calls use
AST_SERIALIZE_CACHE_VERSION (now 7). The output for type strings is the
same today, but the next version bump would silently miss this call.
@github-actions

Copy link
Copy Markdown
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant