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.

Sign up for GitHub

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

Jump to bottom

Update handling and parsing of element segments #1126

Merged
merged 2 commits into from
Jul 17, 2023
Merged

Update handling and parsing of element segments #1126

merged 2 commits into from
Jul 17, 2023

Commits on Jul 15, 2023

  1. Update handling and parsing of element segments 

    This commit started off by updating the spec testsuite submodule to the
latest version and I ended up fixing various bits of parsing element
segments. The changes here are a little subtle, but they are:

* The text format for element segments was refactored and audited to
  attempt to match what's currently written in the spec. The spec
  testsuite doesn't look like it follows the spec perfectly so a few
  adjustments are made. The main change here functionally is that inline
  element segments on `table` definitions might now automatically switch
  a list-of-index text format into a list-of-expression binary format.
  This is what bytecodealliance#952 and its discussion was about. Other than this though
  some parsing has been tightened up as previously some invalid element
  segments were allowed and now require some more specifiers. For
  example `(elem)` was previously considered valid but that is no longer
  valid, instead it must be `(elem func)`.

* The `wasmparser` and `wasm-encoder` crates have both removed the type
  field from their element segment representations, instead only having
  this type information on the list-of-expressions payload. This
  reflects how in the binary format the list-of-indexes form of element
  segments does not have type information. This was primarily done to
  adjust validation to pass a new test where a list-of-indexes element
  segment seems to be expected to fit in a table of `(ref func)`. This
  means that the type of the element segment previously inferred as
  `funcref` was no longer valid and instead it should be `(ref func)`.
  To better represent this these pieces were refactored internally.

* Validation of the `table_init` instruction was updated to perform a
  subtyping check between the element segment and the destination table
  to allow initializing a nullable table with a non-nullable element
  segment, which is a valid operation where the types are not exactly
  equal.

* One extra error message had to be allowed for some new spec tests
  about invalid modules.

Overall this isn't expected to be a major update of any form. Just
another in the long line of updates and adjustments to how element
segments work and validate.
    @alexcrichton
    alexcrichton committed Jul 15, 2023
    Configuration menu
    Copy the full SHA
    e31c58c View commit details
    Browse the repository at this point in the history

  2. Fix benchmark

    @alexcrichton
    alexcrichton committed Jul 15, 2023
    Configuration menu
    Copy the full SHA
    7f989ce View commit details
    Browse the repository at this point in the history