-
Notifications
You must be signed in to change notification settings - Fork 928
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
Naga doesn't check that subexpressions have been emitted. #5763
Comments
It's not clear that this must be a problem. We could simply decide that Naga's validation rules permit subexpressions that are not covered by Here's an illustration of the impact. var<private> x: i32 = 0;
fn inc_x() -> i32 {
x++;
return x;
}
fn f() -> i32 {
x = 0;
return x + inc_x();
} In To get this behavior, however, Naga's WGSL front end must ensure that, in the return inc_x() + x; and the program will return The reason this issue isn't necessarily a bug in Naga's evaluator is that, if the However, I think this is unsatisfying: if a front end neglects to specify when an order-sensitive expression like |
Ensure that every expression whose value is affected by statements' side effects is covered by an `Emit` statement. See the comments on `Expression::is_order_sensitive` for details. Fixes gfx-rs#5763.
I'm not sure what the intention was when we initially implemented the emitting machinery.
I think this is a good idea, we'd avoid a possible footgun. Ideally we'd remove the emitting concept altogether. I really liked the |
Naga doesn't check that each subexpression of an expression used by a statement has been covered by an
Emit
statement.When added to
naga/tests/validation.rs
, the following test should pass, but it fails:The text was updated successfully, but these errors were encountered: