Spec type and module validation, subtyping, and module instantiation. by rossberg · Pull Request #382 · WebAssembly/gc

rossberg · 2023-05-30T14:45:01Z

Also, moved internal type extensions from syntax to validation chapter.

Baseline: #377

Jamesernator · 2023-05-31T07:20:18Z

document/core/util/macros.def

+.. |TARRAY| mathdef:: \xref{syntax/types}{syntax-comptype}{\K{array}}
 .. |TSUB| mathdef:: \xref{syntax/types}{syntax-subtype}{\K{sub}}
 .. |TREC| mathdef:: \xref{syntax/types}{syntax-rectype}{\K{rec}}
 .. |TFINAL| mathdef:: \xref{syntax/types}{syntax-subtype}{\K{filan}}


Typo: filan → final

Oh dear, thanks, fixed.

rossberg · 2023-06-12T19:53:25Z

@conrad-watt, ping.

conrad-watt

Just flagging up that I may fail to catch some semantic errors in matching due to my imperfect understanding - I'm still working to grok.

conrad-watt · 2023-07-18T12:59:25Z

document/core/valid/conventions.rst

+i.e., all :ref:`type indices <syntax-typeidx>` have been :ref:`substituted <notation-subst>` with their :ref:`defined type <syntax-deftype>` and all free recursive type indices have been :ref:`unrolled <aux-unroll-rectype>`.
+
+.. note::
+   Recursive type indices are internal to a recursive types.


nit: "to a recursive types"

conrad-watt · 2023-07-18T13:06:54Z

document/core/valid/conventions.rst

+   \rollrt_x(\TREC~\subtype^\ast) &=& \TREC~(\subtype[(x + i)^\ast \subst (\REC~i)^\ast])^\ast \\
+   &&& (\iff i^\ast = 0 \cdots (|\subtype^\ast| - 1)) \\
+   \unrollrt(\TREC~\subtype^\ast) &=& \TREC~(\subtype[(\REC~i)^\ast \subst ((\TREC~\subtype^\ast).i)^\ast])^\ast \\[2ex]
+   &&& (\iff i^\ast = 0 \cdots (|\subtype^\ast| - 1)) \\


indenting here seems messy - it makes sense to put the side-condition on its own line if the previous line is too long to fit it alongside, but the the &&& then indents the side-condition past the end of the previous line, creating a scroll bar anyway.

conrad-watt · 2023-07-18T13:07:43Z

document/core/valid/conventions.rst

+   \unrollrt(\TREC~\subtype^\ast) &=& \TREC~(\subtype[(\REC~i)^\ast \subst ((\TREC~\subtype^\ast).i)^\ast])^\ast \\[2ex]
+   &&& (\iff i^\ast = 0 \cdots (|\subtype^\ast| - 1)) \\
+   \rolldt_x(\rectype) &=& (\rectype'.i)^\ast & (\iff \rollrt_x(\rectype) = \rectype' = \TREC~\subtype^\ast \\
+   &&& \land i^\ast = 0 \cdots (|\subtype^\ast| - 1)) \\


nit: add whitespace after \land

conrad-watt · 2023-07-18T13:15:36Z

document/core/valid/modules.rst

+
+  * Then the type sequence is valid.
+
+.. math::


probably should move each judgement to a separate line, and separate the premises of the first judgement across multiple lines

Moved rules to separate lines.

conrad-watt · 2023-07-18T13:23:48Z

document/core/valid/types.rst

+     C \vdashcomptype \TSTRUCT~\X{ft}^\ast \ok
+   }
+
+:math:`TARRAY~\fieldtype`


nit: TARRAY should be \TARRAY

conrad-watt · 2023-07-18T13:27:08Z

document/core/valid/types.rst

+Recursive Types
+~~~~~~~~~~~~~~~
+
+:ref:`Recursive types <syntax-rectype>` are validated for a specific :ref:`type index <syntax-typeidx>` that denotes the index of the type defined by the recursive group.


Do we want the additional index to be notated like this? It seems hard to read. I'd expect a judgement of either the form C |- rec subtype* : x or C, x |- rec subtype* ok instead of C |- rec subtype* ok (x)

It's essentially the former, but I wanted to keep the "ok" for consistency with the other type wf judgements. Moving it to the left doesn't look right to me, since it is not really a context.

What about C |-_{x} rec subtype* ok (i.e. a subscript)?

I'm personally quite negative about ok (x) because it looks unstructured/like a typo, and we don't normally use brackets this way.

Subscripts on turnstiles are usually used for distinguishing different relations or modes of relations. So I wouldn't want to put it there.

Not sure I follow what's so bad about ok(x) as a classifier, it's like an indexed ok. Note that I deliberately didn't put a space where you put it. :)

Oh, I get it, I just noticed that the macros mess up the spacing in the rendered version. That should be fixed now.

I think you pushed this on the other PR's branch

Oops, yes, pushed here now.

conrad-watt · 2023-07-18T13:28:29Z

document/core/util/macros.def

+.. |vdashpackedtype| mathdef:: \xref{valid/types}{valid-packedtype}{\vdash}
+.. |vdashstoragetype| mathdef:: \xref{valid/types}{valid-storagetype}{\vdash}
+.. |vdashsubtype| mathdef:: \xref{valid/types}{valid-subtype}{\vdash}
+.. |vdashrectype| mathdef:: \xref{valid/types}{valid-retype}{\vdash}


should this be valid-rectype instead of valid-retype?

conrad-watt · 2023-07-18T13:31:17Z

document/core/valid/matching.rst

+* Or :math:`\heaptype_1` is one of :math:`\I31`, :math:`\STRUCT`, or :math:`\ARRAY` and :math:`heaptype_2` is :math:`\EQT`.

-* Or :math:`\heaptype_2` is a :ref:`type index <syntax-typeidx>` :math:`x_2`, and :math:`\heaptype_1` :ref:`matches <match-heaptype>` :math:`C.\CTYPES[x_2]`.
+* Or :math:`\heaptype_1` is a :ref:`defined type <syntax-deftype>` which :ref:`expands <aux-expand-deftype>` to a :ref:`structure type <syntax-structtype>` and :math:`\heaptype_2` is :math:`STRUCT`.


should STRUCT, ARRAY and FUNC here be macros?

conrad-watt · 2023-07-18T13:33:15Z

document/core/valid/matching.rst

+A :ref:`function type <syntax-functype>` :math:`[t_{11}^\ast] \toF [t_{12}^\ast]` matches a type :math:`[t_{21}^ast] \toF [t_{22}^\ast]` if and only if:

-* The :ref:`result type <syntax-resulttype>` :math:`[t_{11}^\ast]` :ref:`matches <match-resulttype>` :math:`[t_{21}^\ast]`, and vice versa.
+* The :ref:`result type <syntax-resulttype>` :math:`[t_{21}^\ast]` :ref:`matches <match-resulttype>` :math:`[t_{11}^\ast]`.


Just double checking, this change to allow function subtyping is part of the MVP?

Yes, that's why we introduced final types.

conrad-watt · 2023-07-18T13:34:48Z

document/core/valid/matching.rst


-.. note::
-   In future versions of WebAssembly, subtyping on function types may be relaxed to support co- and contra-variance.
+A :ref:`storage type <syntax-storagetype>` :math:`\storagetype_1` matches a type :math:`\storagetype_2` if and only if:


This prose doesn't seem to have an accompanying math block

Because it's just injection. We could write out rules like

C ⊢ valtype_1 ≤ valtype_2 -------------------------- C ⊢ valtype_1 ≤ valtype_2

but that seems odd, and I omitted them elsewhere in similar situations.

conrad-watt

lgtm

rossberg added 3 commits May 26, 2023 12:55

WIP

746b0c6

Merge branch 'main' into spec.valid-types

c85679a

Complete

9bc7b69

rossberg requested a review from conrad-watt May 30, 2023 14:45

Merge branch 'spec.valid-instr' into spec.valid-types

6195c72

rossberg mentioned this pull request May 30, 2023

Spec authoring tracking issue #376

Open

53 tasks

rossberg added 2 commits May 30, 2023 17:08

Fix some errors

2e3f80a

Merge branch 'spec.valid-instr' into spec.valid-types

c6b80c9

Jamesernator reviewed May 31, 2023

View reviewed changes

rossberg added 2 commits May 31, 2023 09:25

Typo

92bb682

Tweak

97e06e0

rossberg mentioned this pull request Jun 26, 2023

Extend validation algorithm appendix #390

Merged

Bit width for packed types

06c497e

rossberg mentioned this pull request Jul 11, 2023

Validation of instructions (plus some infra and fixes) #377

Merged

Base automatically changed from spec.valid-instr to main July 12, 2023 18:34

conrad-watt reviewed Jul 18, 2023

View reviewed changes

rossberg mentioned this pull request Jul 19, 2023

Bulk array validation #401

Merged

rossberg added 2 commits July 19, 2023 11:26

Comments

7516949

Fix spacing

2a857e2

conrad-watt approved these changes Jul 19, 2023

View reviewed changes

rossberg and others added 2 commits July 20, 2023 07:36

Merge branch 'main' into spec.valid-types

518748c

Resolve some more errors and conflicts

fd15280

rossberg merged commit f58ae60 into main Jul 20, 2023

rossberg deleted the spec.valid-types branch July 20, 2023 06:07

Conversation

rossberg commented May 30, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rossberg commented Jun 12, 2023

Uh oh!

conrad-watt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

conrad-watt left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rossberg commented May 30, 2023 •

edited

Loading