Length-prefix recursive types in the type section
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- wasm
- 领域
- compilers
调研方向
Start by reviewing the recursive type grammar described in the issue and wasm-tools pull request #2686, which provides context on parser stack-overflow handling. Determine whether a length-prefixed encoding is appropriate for the component and instance type sections, and document the proposed 1.0 binary-format change and its compatibility implications.
由索引模型根据 Issue 内容生成。
描述
Currently the binary format for component and instance types is self-recursive, for example:
type ::= dt:<deftype>
deftype ::= ...
| ct:<componenttype>
componenttype ::= 0x41 cd*:vec(<componentdecl>)
componentdecl ::= ...
| id:<instancedecl>
instancedecl ::= ...
| 0x01 t:<type>
This recursive nature already needs to be handled by validators but the binary format here means that even just component parsers need to be hardened against this sort of binary format. For example in wasm-tools https://github.com/bytecodealliance/wasm-tools/pull/2686 was a bugfix which adds extra logic to the parser to ensure that stack-overflow doesn't happen on the host where parsers are currently written as recursive-descent parsing.
Elsewhere in wasmparser and wasm's binary format this is often a use case for length-prefixed portions of the binary. For example if a component or instance type were prefixed by not only their numeric item length but also the byte size in the type section it would enable parsers to more efficiently model this as a not-recursive case. Parsing a component type would then yield "here's a chunk of bytes that's supposed to be a component" without actually parsing anything. The caller would then have to parse those bytes itself, but this inverts the control flow a bit where the caller/embedder is now in control of recursion instead of that having to happen internally.
I realize though that this is a breaking change to the binary format so not something we can do in the near-term. Otherwise though I was thinking that this might be a good 1.0-style binary tweak to make it a bit easier on parsers.
- 主要语言
- WebAssembly
- 星标
- 1.4k
- 派生
- 132
- 平均合并
- 3 天 14 小时
- 30 天内合并 PR
- 12
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
WebAssembly/component-model 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
WebAssembly/component-model#609 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
WebAssembly/component-model#743 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
WebAssembly/component-model#742 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 42/100
WebAssembly/component-model#735 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
WebAssembly/component-model#731 · 2 条评论 ·
维护者通常 1 天内回复
查看 WebAssembly/component-model 的全部 Issue
相似的 Issue
-
bug format I/O medium priority rt_lib
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
Invalid model / false unsat: to_fp of real * 2^int with a symbolic rounding mode treats RTN as RTZ未关闭
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 85/100
KhronosGroup/SPIRV-LLVM-Translator#4082 ·
维护者通常 2 天内回复
-
bug diagnostics
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 85/100
bradcypert/plum#227 ·
维护者通常 1 天内回复