-
Notifications
You must be signed in to change notification settings - Fork 361
Add [EnforceRange] to all integers #498
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
|
This change, I like it. Another! |
kdashg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like the verbose name. I might even prefer [EnforceRange] u32. Is there even a use for non-enforced vars?
kvark
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally, I'd prefer us to have semantic typedefs for all the enforced things, like we have for buffer addresses today - GPUBufferSize.
|
I'm out, so please feel free to bikeshed this while I'm out. :)
…On Mon, Nov 18, 2019, 10:10 PM Dzmitry Malyshau ***@***.***> wrote:
***@***.**** approved this pull request.
Ideally, I'd prefer us to have semantic typedefs for all the enforced
things, like we have for buffer addresses today - GPUBufferSize.
------------------------------
In spec/index.bs
<#498 (comment)>:
> @@ -158,7 +158,10 @@ Type Definitions {#type-definitions}
============================
<script type=idl>
-typedef unsigned long long GPUBufferSize;
+typedef [EnforceRange] unsigned long long GPUBufferSize;
+typedef [EnforceRange] unsigned long long enforced_u64;
shouldn't this be camel case, like EnforcedU32?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#498?email_source=notifications&email_token=AAEUBEZKTDE747HL4CXQVY3QUMADTA5CNFSM4JNPAMK2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCL66WTY#pullrequestreview-318630735>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEUBE4RTMHCWEB4LCGSD2TQUMADTANCNFSM4JNPAMKQ>
.
|
|
Discussed and approved the semantics in the 2019-11-25 meeting. Needs bikeshedding on the name. |
b88370c to
efe292c
Compare
kainino0x
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've revised this PR. Please review!
spec/index.bs
Outdated
| typedef [EnforceRange] unsigned long GPUIntegerCoordinate; | ||
| typedef [EnforceRange] unsigned long GPUIndex32; | ||
| typedef [EnforceRange] unsigned long GPUSize32; | ||
| typedef [EnforceRange] long GPUSignedOffset32; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: I tried not to go too overboard with the number of different types, so consolidated some of them into these generic ones.
IMO, no. |
kdashg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather see u32_strict (U32Strict? Uint32Strict?) or similar, rather than hiding the sizes behind semantic types.
|
This was discussed in the 2020-01-06 meeting |
kvark
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
![]()
|
Approved, but has rebase conflicts. @kainino0x |
e5a877f to
7fb3149
Compare
- Rename GPUBufferSize to GPUSize64 (it's also used for ArrayBuffer). - Use GPUSize32 instead of GPUIntegerCoordinate for rowPitch/imageHeight. (They have the same definition though.)
7fb3149 to
75f212b
Compare
|
Merging after merging with master, and with minor nonfunctional changes (see the last commit) |
Adds [EnforceRange] to most of the integer types in WebGPU according to my spec change: gpuweb/gpuweb#498 . Note that there is one place where it was not possible to match that spec change, as that the spec change violates WebIDL (in spirit). - Interface `const` values for flags can't use [EnforceRange]'d types. The upstream bug for that is gpuweb/gpuweb#549 There is a manual workaround in cts.html for an incompatibility between the variant strings and run_web_tests: <!-- MANUALLY EDITED: run_web_tests doesn't like tests which end in '/', so the '/' is replaced with '%2F' manually for now --> Bug: 1050909 Change-Id: Ic84f102d138204328fe0d4fb7cb46622c7104630 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2048998 Auto-Submit: Kai Ninomiya <kainino@chromium.org> Commit-Queue: Yutaka Hirano <yhirano@chromium.org> Reviewed-by: Yutaka Hirano <yhirano@chromium.org> Reviewed-by: Austin Eng <enga@chromium.org> Cr-Commit-Position: refs/heads/master@{#762254}
* Add [EnforceRange] to all integers * more integer types * use GPUSize32 for first* * Changes to naming and which types are used - Rename GPUBufferSize to GPUSize64 (it's also used for ArrayBuffer). - Use GPUSize32 instead of GPUIntegerCoordinate for rowPitch/imageHeight. (They have the same definition though.)
* Add [EnforceRange] to all integers * more integer types * use GPUSize32 for first* * Changes to naming and which types are used - Rename GPUBufferSize to GPUSize64 (it's also used for ArrayBuffer). - Use GPUSize32 instead of GPUIntegerCoordinate for rowPitch/imageHeight. (They have the same definition though.)
* Implement api,operation,rendering,draw:arguments:* * Address comments from code review * Update src/webgpu/api/operation/rendering/draw.spec.ts
[EnforceRange]is the most-strict and least-surprising mode ofnumber-to-integer conversion in WebIDL. (The default is modular, the other option is[Clamp].)[EnforceRange]rounds the (double-precision floating point)numberto an integer, then throws if it's outside of the range of the integer type. It has the benefit that removing this attribute would be a non-breaking change (in that it would change from throwing to not-throwing).I've been meaning to do this for a long time, but I didn't realize that it was an attribute on the type and not the fields/parameters themselves, or I might have done this before removing all the typedefs. 🙃
I'm not attached to using typedefs, it just makes it slightly more apparent if something diverges from this (IMO) (the word
longwill appear). This PR does not leave any unenforced integer types.Austin did some quick measurements in Chrome's bindings, and this doesn't seem to impact performance in the non-failure case, for us.
Preview | Diff