Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Length-prefix recursive types in the type section

Abierto
  • ¿Algo no está bien?
#732 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
wasm
Área
compilers

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
WebAssembly
Estrellas
1.4k
Forks
132
Merge medio
3 d 9 h
PR fusionados (30 d)
10

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de WebAssembly/component-model

Todos los issues de WebAssembly/component-model

Issues similares

Más issues de Compilers

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.