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.

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

Rename anyref to externref to match proposal change #2900

Merged
merged 1 commit into from
Jun 10, 2020

Conversation

jayphelps
Copy link
Contributor

@jayphelps jayphelps commented Jun 9, 2020

anyref future semantics were changed to only represent opaque host values, and thus renamed to externref.

Chromium was just updated to today (not yet released). I couldn't find a Mozilla bugzilla ticket mentioning externref so I don't immediately know if they've updated yet.

WebAssembly/reference-types#87

scripts/gen-s-parser.py Outdated Show resolved Hide resolved
@@ -229,7 +229,7 @@ def has_shell_timeout():
'--wasm-staging',
'--experimental-wasm-eh',
'--experimental-wasm-simd',
'--experimental-wasm-anyref',
'--experimental-wasm-externref',
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should we use this opportunity to also change this to --experimental-wasm-reftypes` to match browser flags since I think the rest of the proposal is implemented too under the same flag?

Copy link
Member

Choose a reason for hiding this comment

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

sounds good to me

src/wasm/wasm-s-parser.cpp Outdated Show resolved Hide resolved
@jayphelps jayphelps force-pushed the externref branch 2 times, most recently from 2fd7464 to 5bb1c9c Compare June 9, 2020 19:13
@jayphelps jayphelps marked this pull request as draft June 9, 2020 19:15
@tlively tlively requested a review from aheejin June 9, 2020 19:16
@binji
Copy link
Member

binji commented Jun 9, 2020

The other major change here is to require a type parameter for ref.null, though I suppose that could be done in a separate PR.

@jayphelps
Copy link
Contributor Author

@binji wasn't the discussion today about removing that type param for ref.null? I was multitasking so I may have misunderstood.

;; t <: anyref for all reftypes t
;; nullref <: anyref, nullref <: funcref and nullref <: exnref
;; t <: externref for all reftypes t
;; nullref <: externref, nullref <: funcref and nullref <: exnref
Copy link
Member

Choose a reason for hiding this comment

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

The actual subtyping relationship will have to be updated, but I think that can be a separate PR as well. Can you add a TODO here?

Copy link
Contributor Author

@jayphelps jayphelps Jun 9, 2020

Choose a reason for hiding this comment

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

Oh yikes. Indeed. I digged a bit and it touches area of the codebase I'm not comfortable touching at the moment, e.g. fuzzer, so I'll indeed comment this as a TODO comment. Thanks!

@tlively
Copy link
Member

tlively commented Jun 9, 2020

@binji wasn't the discussion today about removing that type param for ref.null? I was multitasking so I may have misunderstood.

No, that was about removing type type immediate for ref.is_null.

@jayphelps
Copy link
Contributor Author

The emscripten tests are failing but the errors are unclear to me and I have to pause on this until this evening. If someone happens to have a second to grok what the issue is it'd be appreciated https://github.com/WebAssembly/binaryen/pull/2900/checks?check_run_id=755283093

@sbc100
Copy link
Member

sbc100 commented Jun 9, 2020

Hmm.. looks like maybe non-determinism in the validator causing the tests to produce different output between runs maybe? I can't see that its related to this PR in any way, can you?

@sbc100
Copy link
Member

sbc100 commented Jun 9, 2020

Re-running the CI to see its a flake.

@aheejin
Copy link
Member

aheejin commented Jun 9, 2020

@jayphelps

The emscripten tests are failing but the errors are unclear to me and I have to pause on this until this evening. If someone happens to have a second to grok what the issue is it'd be appreciated https://github.com/WebAssembly/binaryen/pull/2900/checks?check_run_id=755283093

You deleted a trailing whitespace in test/binaryen.js/kitchen-sink.js.txt :)

Copy link
Member

@aheejin aheejin left a comment

Choose a reason for hiding this comment

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

Thanks for taking care of this!

src/asmjs/asm_v_wasm.cpp Outdated Show resolved Hide resolved
@jayphelps jayphelps force-pushed the externref branch 3 times, most recently from 3f7966b to 6a5b74f Compare June 10, 2020 04:20
@jayphelps
Copy link
Contributor Author

jayphelps commented Jun 10, 2020

Phew! OK all green now. The issue was that search and replace in vscode applies default style rules too, which include no trailing whitespace. There is a single space after , on that kept getting removed if I saved that file. Disabled that rule and resaved it with the space. Thanks to @aheejin for pointing the issue out!

I think this is ready for final review/merge

@jayphelps jayphelps marked this pull request as ready for review June 10, 2020 04:40
Copy link
Member

@aheejin aheejin left a comment

Choose a reason for hiding this comment

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

It looks good to merge, modulo the super minor nit I just posted here.

Unrelated question: Are you also planning to do update Binaryen codebase on other subtyping-related changes (new instructions and such)? That'd be also appreciated; I'm just asking in order not to do the duplicate work from my side :)

test/passes/instrument-locals_all-features.wast Outdated Show resolved Hide resolved
@aheejin
Copy link
Member

aheejin commented Jun 10, 2020

Thanks! One more thing, force-pushing makes reviewing only addition changes harder. If possible, please just add additional commits! :) (You don't need to rebase all commits into one each time, because we are gonna squash all commits into a single commit when merging this PR anyway)

@jayphelps
Copy link
Contributor Author

@aheejin will do!

@jayphelps
Copy link
Contributor Author

@aheejin Unfortunately it's unlikely I'll have time right now, as this rename was the only change I needed to unblock my work. I looked a bit into the other changes needed and they touch parts of the codebase I'm not yet familiar with (e.g. fuzzing code) and I can't spare the cycles at the moment to fully grok it and any potential fallout implications. I wish though! This stuff is a lot of fun.

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

Successfully merging this pull request may close these issues.

None yet

5 participants