Skip to content

Allow parsing of blocks with a type reference #4236

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

pmatos
Copy link
Contributor

@pmatos pmatos commented Oct 12, 2021

Blocks are not allowed to have input parameters.

Currently only blocks of the form are supported:

(block $label (result ...)
  ...)

This patch enables this type of block declaration:

(type $ty (func (param) (result ...)))

(block $label (type $ty)
  ...)
@pmatos
Copy link
Contributor Author

pmatos commented Oct 12, 2021

This is still in draft mode as I am still working out an issue with the build.

@tlively @kripken What's the best place for a test for this?

@pmatos pmatos force-pushed the block-type-work branch 2 times, most recently from 0675ab1 to 8b6dbc6 Compare October 12, 2021 05:07
Blocks are not allowed to have input parameters.
Adds new test `blocks.wast`.

Currently only blocks of the form are supported:
```
(block $label (result ...)
  ...)
```

This patch enables this type of block declaration:
```
(type $ty (func (param) (result ...)))

(block $label (type $ty)
  ...)
```
@pmatos
Copy link
Contributor Author

pmatos commented Oct 12, 2021

This is still breaking the validator. There's some strange case where apparently the parser is for:

(type $ty (func (param) (result i32)))
(func $withblock-typeref (param) (result i32)
    (block $label (type $ty)
      (i32.const 0)))) 

generating a Rtt for (type $ty) rather than a Ref.

// FIX: If we don't pass a second argument, this will call Type::Type(Rtt)
// instead of Type::Type(Ref, NonNullability), although at this point
// I am not sure the NonNullable here is the right thing to do.
return Type(parseTypeRef(typeref), NonNullable);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is definitely strange, if I don't pass the NonNullable, I would expect this to create a Ref but it creates a Rtt simply because the constructor is the one that expects a single argument.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the implicit conversions cause that, and they can be a little confusing, but they do make sense. An RTT can be constructed from a heap type, but nothing else - a reference must be either nullable or not, so that is not optional in its constructor.

But maybe the issue here is that parseTypeRef is not the right thing to call. That returns a heap type, but here we actually want a type. That is, it needs to parse something that is more than just a heap type, including whether it is null or not.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the only existing caller to parseTypeRef is in type declarations, where indeed heap types are declared. So perhaps it should be renamed to parseHeapType?

@@ -575,6 +575,11 @@ void FunctionValidator::validateNormalBlockElements(Block* curr) {
}
if (curr->list.size() > 0) {
auto backType = curr->list.back()->type;
if (curr->type.isRef()) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added this just to check how far we could go but not very far because there's some validation issue then later on the visitFunction. I think at this point, we need to check that the referenced type has no inputs, but I can't find a way to access the referenced TypeInfo (I think it's where it's stored). Any hints here?

(module
(type $ty (func (param) (result i32)))

;; (func $withblock-result (param) (result i32)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is ok and passing, so to simplify my life I just commented it.

@tlively
Copy link
Member

tlively commented Oct 14, 2021

Probably a new test in test/lit would be good for this. For a very thorough test script, see the RUN lines in test/lit/table-first-special.wast.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants