New testsuite organization
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- wasm
- Domain
- testing-qa
Research direction
Start with the linked conversation in PR 129 and compare the wasm-3.0 folder structure with the duplicated binary.wast and binary0.wast files. Determine whether proposal-level separation or descriptive filenames is acceptable for Chicory’s .wast-based generation; done means documented guidance or an agreed testsuite organization change.
Written by the indexing model from the issue text.
Description
Hello 👋
I’m following up here as suggested in this conversation.
Before the PR landed, we didn’t notice that a new testsuite folder structure was introduced.
As runtime developers, we now face a challenge: it’s much harder to implement proposals one at a time.
I’m looking for guidance on how to proceed and what to expect going forward.
In chicory, we generate unit tests based on .wast files.
Previously, we relied on the folder structure to include only the proposals implemented at each stage.
Now that everything is under wasm-3.0, we either need a way to separate files by proposal or provide at least a minimal implementation of all proposals opcodes upfront just to get parsing to pass.
I also noticed that in some cases (e.g. binary.wast and binary0.wast) files have been duplicated.
Would it be an acceptable middle ground to keep proposals separated at the file level and use more descriptive names, such as binary_eh.wast, to indicate which proposal they cover?
Thanks!
- Dominant language
- WebAssembly
- Stars
- 3.5k
- Forks
- 539
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 13
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WebAssembly/spec
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
WebAssembly/spec#2245 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
WebAssembly/spec#2235 · 9 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
WebAssembly/spec#2196 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
WebAssembly/spec#2155 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
WebAssembly/spec#2150 · 1 comment ·
All issues in WebAssembly/spec
Similar issues
-
refactor
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
bug follow-up-work-in-progress from-review-extraction llm-providers python severity:should-fix
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
type/automation type/tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
bug core
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
[Duplicate Code] Share the Cloud Hypervisor network-plan fixture between launch and config tests Opencode-quality refactoring
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
github/gh-aw-firewall#8974 ·