WebAssembly / WebAssembly/binaryen

Assumptions for public types under --closed-world

Open
#8,754 11 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
WebAssembly
Stars
8.6k
Forks
885
Avg merge
1d 19h
Merged PRs (30d)
69

Description

I spoke with @tlively following a discussion here and we're not sure about the assumptions we can make about references of public types under --closed-world. We came up with this table describing when references may originate from outside of the module and be passed into it:

Can a reference originate from outside our module?
Public Type Private Type
Open World Yes No
Closed World ? No

For private types, open or closed world doesn't matter because even if the hosting environment creates a reference, there's no way for them to pass it to us. For closed world, the CLI help says this:

Assume code outside of the module does not inspect or interact with GC and function references, even if they are passed out. The outside may hold on to them and pass them back in, but not inspect their contents or call them.

Based on this, it sounds like a host environment would have no way of producing any kind of reference, even to a public type. If it did produce such a reference, it would be able to pass it to the module but it can't create one to begin with. It could instantiate an unrelated Wasm module that creates references, but it sounds like that would violate the assumptions of closed world. My thought based on this is that the answer is 'no' for public types in a closed world. Is that correct, or is it possible for references to originate outside of our module for public types in a closed world?


This is relevant for the indirect call support in GlobalEffects (#8609). We currently do analysis on indirect called types when --closed-world is enabled. But if we can't assume that references to public types must originate from our module in --closed-world, then it would be possible for the hosting environment to create their own function that then becomes a target of an indirect call of a public type, in which case we should give up and conservatively assume all effects for that type (meaning the analysis would be overly-optimistic and wrong today).

(Semi-related: in either case, there are some improvements that can be made for private types, since these can be reasoned about even in an open world)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the --closed-world CLI help and the indirect-call analysis in GlobalEffects referenced by #8609. Resolve whether public references can originate outside a closed-world module, record the decision, and ensure the analysis is conservative if they can; private-type improvements are a separate follow-up.

Written by the indexing model from the issue text.

Assessment

Tech stack
wasm
Domain
compilers
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.