Assumptions for public types under --closed-world
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- wasm
- 領域
- compilers
調査の方向性
まず --closed-world の CLI ヘルプと、#8609 で参照されている GlobalEffects の間接呼び出し解析を確認してください。public な参照が closed-world モジュールの外部から発生し得るかどうかを判断し、その決定を記録し、発生し得る場合は解析が保守的になるようにしてください。private-type の改善は別のフォローアップとします。
索引モデルが issue の本文から書いたものです。
説明
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)
- 主要言語
- WebAssembly
- スター
- 8.7k
- フォーク
- 893
- 平均マージ
- 1日 18時間
- マージ済み PR（30日）
- 79
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
WebAssembly/binaryen のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
WebAssembly/binaryen#9185 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
WebAssembly/binaryen#9135 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 半日 初心者へのやさしさ 76/100
WebAssembly/binaryen#9018 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
WebAssembly/binaryen#9186 ·
メンテナーはふだん 1 日以内に返信
-
LoopInvariantCodeMotion: `struct.new` is hoisted out of a loop, so all iterations share one objectオープン
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
WebAssembly/binaryen#9184 ·
メンテナーはふだん 1 日以内に返信
WebAssembly/binaryen の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
objectionary/eo#9182 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
メンテナーはふだん 1 日以内に返信
-
todo:ticket
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 92/100
iree-org/iree#24991 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信