-
Notifications
You must be signed in to change notification settings - Fork 303
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
Clarify whether type checking occurs for short-circuited RHS expressions #4551
Comments
The requirements on element count in array type definitely seem wrong upon reflection:
Delaying all size checks to pipeline creation seems wrong given how few places can utilize a pipeline dependent value. I highly doubt any implementation would be so strict. At least the final bullet should be changed to something along the lines of:
That doesn't answer whether the question raised in this issue directly though. My opinion is that it would make sense to fully evaluate the type before evaluating the surrounding expressions. |
Refs gpuweb#4551 * If the array element count expression is a const-expression, invalid values should be shader-creation errors
Note: Array sizes that depend on override declarations have a special type checking rule that allows them to be checked at shader-creation time. The sizes must be:
Ok, that aside, I think it's reasonably clear from 6.1 Type Checking:
I'll emphasize "each expression" must be mapped to its static type. It doesn't matter if the expression is ever evaluated. Concretely:
|
heh. It's been pointed out I missed the array type (!) sqrt(-1) would be a domain error --> shader creation error. But fair point, if we had a const-expr indeterminate value .... but I think that can't happen, or we would already have a shader-creation (or pipeline-creation) error. For the override-expression case, you'd argue we don't have an actual array type until the override-expression is evaluated. But you can determine type matching. So yeah, we should tweak the "each expression is mapped to a static type" to also allow the case of using the symbolic sized array type when the size is an override-declared identifier.
|
So, does this mean we have to run certain portions of const-eval, to calculate Do we have a list of the places where this "pre-const-eval-const-eval" has to happen? Is it just array expressions? |
I don't think that type checking and expression evaluation are distinct stages of WGSL compilation. They are necessarily intertwined - you can't always do type checking without evaluating some expressions, and you can't always evaluate those same expressions until some amount of type checking has happened. You can see this by extending the original example with more nested array expressions:
Here, the inner |
Right, but in this case, due to the short circuit, we shouldn't be evaluating the entire Maybe it falls out naturally that we can eval just the parts needed for type checking and not the full expression. |
Here are a few example cases driving discussion here at Google, that I think get to the core of the matter:
|
WGSL 2024-04-16 Minutes
|
WGSL's const-expr section contains the following note:
This means that invalid constant expressions on the RHS of a short-circuited operator do not cause shader creation errors, because they are never evaluated. For example:
It's less clear whether rules around type validity that require sub-expression evaluation are included in this. For example, consider:
The
array
type requires a positive integer element count, but in order to validate that in the above cases we first have to evaluate the element count expressions. Are these evaluations guarded by the above note, or are they considered to be evaluated independently of the expression tree that the type appears in?The text was updated successfully, but these errors were encountered: