Repository navigation
Enhance type annotations in tlbparser and codegenerator ahead of addressing the VT_I1 mapping issue. - #973
Merged
junkmd merged 13 commits intoOct 21, 2026
Conversation
junkmd
added
enhancement
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #973 +/- ##
==========================================
+ Coverage 89.55% 89.56% +0.01%
==========================================
Files 143 143
Lines 14147 14170 +23
==========================================
+ Hits 12669 12692 +23
Misses 1478 1478 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
junkmd
changed the title
tlbparser and codegenerator ahead of VT_I1 refactoring.tlbparser and codegenerator ahead of addressing VT_I1 mapping.
junkmd
changed the title
tlbparser and codegenerator ahead of addressing VT_I1 mapping.tlbparser and codegenerator ahead of addressing the VT_I1 mapping.
junkmd
changed the title
tlbparser and codegenerator ahead of addressing the VT_I1 mapping.tlbparser and codegenerator ahead of addressing the VT_I1 mapping issue.
junkmd
force-pushed
the
enhance_type_annos_to_tlbparser_and_codegen
branch
2 times, most recently
from
October 21, 2026 02:39
2695fee to
2850905
Compare
…ting rules in `pyproject.toml`
There used to be a special-case path for `name="void"` where instance attributes `size` and `align` were not assigned, but in the current implementation that branch is already guarded by the type identity itself, so it is not a realistic runtime problem. In other words, `void` is already treated as an exceptional case at the parser boundary, and the implementation does not expect a generic attribute test such as `hasattr`/`getattr` to be needed for it. The policy here is to treat `void` as a sentinel value in this type parser even though C itself defines it as an incomplete type, for which `sizeof(void)` is not meaningful. `FundamentalType` is not a perfect model of C types; it is a Python-side representation that needs to expose `size` and `align` as attributes for downstream code to consume consistently. In that model, the `(0, 0)` assignment keeps `void` consistent without requiring a special case in the downstream code. This is therefore not a claim that `void` is a true zero-sized, zero-aligned C object in the language-theoretic sense; it is simply the parser's policy for encoding an incomplete type in a model that requires those fields to exist.
…ng wildcard import.
…ations in `tlbparser`.
…methods in `CodeGenerator`.
…rfaces` in `CodeGenerator`.
… of types is needed.
junkmd
force-pushed
the
enhance_type_annos_to_tlbparser_and_codegen
branch
from
October 21, 2026 02:42
2850905 to
4053b50
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR introduces explicit type annotations to
tlbparserandcodegenerator(notably introducing theParsedTypeunion) and cleans up related type definitions and imports.This is a preparatory refactoring intended to provide type annotations ahead of addressing the
VT_I1mapping issue(#969), ensuring subsequent refactorings proceed smoothly and safely.Except for the constructor of
FundamentalType(which was verified through codebase investigation to be safe to modify in order to uphold the type contract), all changes in this PR intentionally avoid modifying runtime behavior.While replacing
Anywith stricter type annotations leads to type checker warnings due to the lack of runtime type-narrowing in the existing code, we have intentionally scoped this PR to avoid altering runtime logic at this stage.