Merge in the latest spec #38
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Support and test empty list syntax
Support alternate sign operators and matching
This was already done upstream in web-platform-tests/wpt#50557.
Internalise half/zero flags into vcvtop
…ebAssembly#1964) Based on the discussion in WebAssembly#1950, splits tests for bulk memory, multi-memory, and memory64 (including test generators) into separate directories and files. bulk memory is considered an "artificial" dependency of the other 2 proposals, so for example tests which cover the intersection between bulk memory and memory64 go into the memory64 directory.
* Initial commit
* Initial setup and overview
* Update proposal
* Adopts builtin modules approach
* Adds section of polyfilling
* Adds section on feature detection
* Adds cast/test builtins
* Adds future extension ideas for
- binding memory
- utf8/wtf8
- evolving the type signatures
* Address review feedback
* Rename concatenate to concat
* Editorial changes
- Eliminate usage of 'builtin module' in description. This is not essential to the proposal and
causes confusion around a similarly named JS proposal, which had different goals.
- Clarify some minor points.
- Make JS-API changes to WebIDL comprehensive.
- Reword feature detection section to actually propose change to WebAssembly.validate method
* Tighten up definitions of function builtins
- Function builtin behaviors is defined using 'create a host function'
- Clarify behavior around monkey patching using standard language
- Clarify edge cases around nullability
- Clarify edge cases around unsigned/signed integers
- Restrict 'substring' behavior to normal cases
- Use wasm helpers for when wasm instructions are needed
* Rework support for WTF-8
The existing WTF-8 operation in this proposal violated one of the goals of the
proposal: "don't create substantial new functionality" by introducing WTF-8
transcoding support to the web platform without prior precedent. The WTF-8
operation is removed because of this.
The naming for WTF-16 operations is reworked to refer to 'charCodes' instead
as that is what the JS String interface uses.
We could support UTF-8 transcoding by referring to the TextEncoder/TextDecoder
interfaces, so this commit adds support for that.
* Review comments
* Update substring range checking
* Fix mutability of array i8
Fixes #19.
* Add streaming-related functions
Fixes #19
* Clarify behavior of flags and function names
Fixes #17.
* Fix link to type-imports prposal in js-string-builtins/Overview.md
* Clarify feature detection scheme
Explain that users should validate modules that deliberately produce link errors to test for support for particular builtins.
* Add test for js-string-builtins
This commit adds a basic suite of tests for the js-string-builtins.
This is done by defining a polyfill module matching the overview,
and then comparing the host provided builtins against the polyfill
on representative inputs.
* Fix type signature of 'concat'
Fixes #24.
* Add section on string constants, including Struct.from
* Rework to use imported string constants idea
* Fixup typos
* Add missing start parameter to measureStringAsUTF8 overview
* Update Overview.md
* Many small improvements
- Syntax highlighting
- Added links
- Code font
- Consistency
- Grammer fixes
* Update proposals/js-string-builtins/Overview.md
* Fix nullability for string constants
* Expand section on string constants
* Revert unintentional change to builtins field
* Add note about empty imports object
* Initial outline of builtin support
* Expand specification of builtins
* Remove unneeded modification to embedding spec
* Initial string constants support
* Fix module constructor to handle options
* Don't freeze internal instantiation of builtins and string constants
* Move UTF-8 support to a future proposal
* Remove DS_Store
* Remove DS_Store
* Mark up options appropriately
* Make UnwrapString an abstract-op and use it to implement cast
* Consistently use "steps" instead of "algorithm" for builtins
* Add test
* Add stubs for the rest of the operations
* Add fromCharCode
* Switch to using the Call abstract op, and add fromCodePoint
* Add length
* Add charCodeAt and codePointAt
* Add concat
* Add substring
* Use angle quotes appropriately
* Add basic support for fromCharCodeArray
Needs more detail to properly integrate with GC array ops.
* Make fromCharCodeArray slightly less formal
This avoids having to refer to actual Wasm instructions,
since after all this is a host function.
* Add intoCharCodeArray
* Add equals and compare
* Review fixes for builtin steps
* Tweak wording for trapping in builtins
* Fix spec to separate builtin name used for imports and compile options
* Add note about patching the String builtins
* Add more tests
* Don't validate that every builtin set option is valid
* Fix null-handling for `equals` in test and polyfill
Equals specifically allows null inputs. Update the JS API tests
and the polyfill to match.
* Editorial: replace Type AO with new ECMA-262 type test convention
* actually remove Type
* support per-component polyfill fallbacks
* spec rework
* typo
* Editorial: Align with Web IDL specification
* [js-api] Fix incorrect return statement in 'validate builtin set names'
* [js-api] Remove copy-pasted if statements
* Revert changes to conf and README to prepare for merging
* [tests] Remove tentative from js-string tests
* Expand JS builtin functypes
* Add change history entry
* [js-api] Improve formatting
---------
Co-authored-by: Deepti Gandluri <dtig@users.noreply.github.com>
Co-authored-by: Martin Kustermann <kustermann@google.com>
Co-authored-by: Thomas Lively <tlively@google.com>
Co-authored-by: Ömer Sinan Ağacan <omeragacan@gmail.com>
Co-authored-by: Thomas Steiner <tomac@google.com>
Co-authored-by: Adam Klein <adamk@chromium.org>
Co-authored-by: Michael Ficarra <m.ficarra@f5.com>
Co-authored-by: Guy Bedford <guybedford@gmail.com>
Co-authored-by: autokagami <saschanaz+autokagami@outlook.com>
* [js-api] Set the implementation limit for memory types memory32 is the full 4GiB range. memory64 is at 2^37-1 so that when the page size is converted to bytes it is less than the JS MAX_SAFE_INTEGER value. Leave the runtime limits for memory sizes as-is. * [js-api] Don't allow memories without max in toResizableBuffer * [js-api] Remove unnecessary guard on maxsize We must allow maxsize greater than 4GiB for memory64. The impl limit for memory64 will ensure the maxsize is within MAX_SAFE_INTEGER. * [js-api] Fix ordering of instructions * [js-api] Fix units * Fix Assert in memory.grow
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Very large diff, it's spectec.
current diff from spectec merge point