Skip to content
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

forbid spelling pointer types that are not instantiable #1427

Closed
dneto0 opened this issue May 17, 2022 · 1 comment
Closed

forbid spelling pointer types that are not instantiable #1427

dneto0 opened this issue May 17, 2022 · 1 comment
Assignees
Labels

Comments

@dneto0
Copy link
Contributor

dneto0 commented May 17, 2022

From spec change gpuweb/gpuweb#2904

E.g. the following shaders must produce shader-creation error

type p = ptr<workgroup,array<i32>>;
fn foo( p: ptr<workgroup,array<i32>> ) { }
@dneto0 dneto0 added the wgsl label May 17, 2022
@dneto0 dneto0 self-assigned this Jul 7, 2023
@dneto0 dneto0 mentioned this issue Jul 7, 2023
5 tasks
dneto0 added a commit to dneto0/cts that referenced this issue Jul 10, 2023
…ions

Check combinations of address space and access mode.
Check that we can read from any pointer.
Check that we can write to pointers that we should be able to, including
when the let infers the pointer type.

The store type of a pointer must be instantiable as the store type
of a variable that could be declared somewhere.

A function formal parameter must not be pointer to workgroup,
where the store type is atomic or contains an atomic.

Fixes: gpuweb#2832 gpuweb#1427 gpuweb#1589
dneto0 added a commit that referenced this issue Jul 12, 2023
* Refactor helpers into util.js

* Fix logic of picking a valid address space.

* Fix addressSpaceExpander

When expansion produces an empty list, it kills the parameterization.
Instead, generate a list with an empty string.

Propagate the type signatures as needed.

* Validate ptr type spelling for lets and params of user-declared functions

Check combinations of address space and access mode.
Check that we can read from any pointer.
Check that we can write to pointers that we should be able to, including
when the let infers the pointer type.

The store type of a pointer must be instantiable as the store type
of a variable that could be declared somewhere.

A function formal parameter must not be pointer to workgroup,
where the store type is atomic or contains an atomic.

Fixes: #2832 #1427 #1589

* Avoid adding address space info to t.params

Push the lookup of address space info into the helpers.

* s/explicitMode/explicitAccess/

Per review feedback

* Drop redundant "as string"
@dneto0
Copy link
Contributor Author

dneto0 commented Jul 12, 2023

Fixed by #2840

@dneto0 dneto0 closed this as completed Jul 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Open (no TODO)
Development

No branches or pull requests

1 participant