-
Notifications
You must be signed in to change notification settings - Fork 72
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
Document new implementation-defined limits #360
Conversation
Current dependencies on/for this PR: This comment was auto-generated by Graphite. |
The one limit we discussed that is not in this PR is the byte limit on the size of global initializers. I decided not to include it because it is under discussion separately in the extended-const proposal: WebAssembly/extended-const#15. |
proposals/gc/MVP.md
Outdated
@@ -779,6 +779,14 @@ The opcode for heap types is encoded as an `s33`. | |||
| 0xfb70 | `extern.internalize` | | | |||
| 0xfb71 | `extern.externalize` | | | |||
|
|||
## Implementation-defined Limits |
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.
Since these are constraints of the JS API spec, it should make more sense to move this section down below and turn it into a subsection of that one.
I've now fixed the link in MVP.md to point to the actual bikeshed document containing the JS spec (rather than the outdated MVP-JS.md) and I've put the new limits directly into the relevant section in the bikeshed doc. |
Hm, I think we should update the MVP-JS doc to match the status quo. Otherwise, we're losing the documentation of that part of the proposal and its design. Looking at the final spec provides no useful information about what the proposal was about. We are intentionally keeping around design docs in the proposals directory, after all. |
Ok, this now documents the limits in a revamped MVP-JS.md doc as well as in the actual spec doc. |
Based on discussion in #335 and subgroup meetings.
The new limits were previously merged in #360, but apparently that PR was to another branch that itself was never merged. Reland that change with two additional fixes: - Add digit separators in the numbers to improve readability and match the formatting of other limits. - Add an explicit limit of 1,000,000 types per recursion group. This is not intended to be a functional change, but this limit was previously left implicit.
The new limits were previously merged in #360, but apparently that PR was to another branch that itself was never merged. Reland that change with two additional fixes: - Add digit separators in the numbers to improve readability and match the formatting of other limits. - Add an explicit limit of 1,000,000 types per recursion group. This is not intended to be a functional change, but this limit was previously left implicit.
Based on discussion in #335 and subgroup meetings.
Closes #335.