-
-
Notifications
You must be signed in to change notification settings - Fork 15
Split compiler into multiple passes #64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #64 +/- ##
==========================================
- Coverage 77.11% 76.65% -0.47%
==========================================
Files 159 185 +26
Lines 21656 23343 +1687
Branches 6456 7041 +585
==========================================
+ Hits 16701 17894 +1193
- Misses 4853 5351 +498
+ Partials 102 98 -4
... and 2 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
this is to get a better view of the work remaining
This is already handled in a better way by the SpirvAstVisitor
…s in assignment When using partial compilation, struct member indices may become unknown and should be resolved later. When this happens AccessMemberExpression will be generated instead of AccessFieldExpression Maybe member indices should be kept and take disabled/unknown field into account?
Structs field now have their own dedicated node: AccessField
Handling module import when indices can't be resolved caused (probably) unsolvable issues when a compiled modules was imported into another one All code generation test passes
…on structs Previous compiled NZSL AST would use AccessIndex instead of AccessField for structs
Improves performance also for BindingResolverTransformer as it doesn't need to visit function content
Also fix struct field checking
It could be out of bounds (due to same-type constraint) It could be triggered even in a partial compilation
… partial compilation
If fromExpr is replaced by another expression (by the ComputeConstantValue call), fromExprType is no longer valid
it breaks variable declaration inside branches, such as ``` const if (HasNormal) let normal: vec3[f32]; ```
…ntQueryCallback isn't set or doesn't find constant
Uh oh!
There was an error while loading. Please reload this page.