Handle type-closing chevrons adjacent to an initializer assignment

Abierto
  • ¿Algo no está bien?
#992 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
compilers

Línea de trabajo

Start with type parsing in front/parser/src/parser/types.rs and storage declarations in front/parser/src/parser/decl.rs, then inspect the lexer’s compound-operator handling. Reproduce with array<i32,1>=[1] and ptr<i32>=null while comparing the spaced forms and genuine >=/>> expressions. Done means the agreed compact-or-spaced policy is consistent across the listed generic types, diagnostics identify the exact boundary when rejected, AST/HIR behavior is equivalent for accepted forms, and source spans remain accurate.

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

Descripción

bug help wanted

Problem

A storage declaration using array<i32,1>=[1] or ptr<i32>=null fails while the same declaration with whitespace between > and = succeeds. The diagnostic consumes past the chevron/operator boundary and says a semicolon is missing, rather than explaining the actual boundary problem.

Starting points: type parsing, storage declarations, and the lexer compound-operator handling. This differs from the error-message preservation work in #971 and nested generic comma/chevron tests in #393.

Reproduction

Audited canonical master 540728c2eb6cc12f5c69c3fb3fdb96e07ba059a4 on Linux amd64 with a checkout-built Wave 0.0.1-alpha-dev, matching checkout std, Rust 1.89.0 and LLVM 21.1.8. Both check and build --emit=ir, with --error-format=json, reject:

fun main() {
    var a: array<i32,1>=[1];
    var p: ptr<i32>=null;
}

array<i32,1> = [1] and ptr<i32> = null are accepted controls. The errors are expected ';' in storage declaration; the pointer case highlights null, after the problematic boundary.

Scope

Resolve the type/assignment token boundary in its parsing context, retaining correct spans for any split tokens. Keep actual expression >=, >> and compound shifts unchanged. If the language intentionally requires whitespace here, document that choice and issue a boundary-specific diagnostic instead of the misleading semicolon error.

Please mention @LunaStev to discuss the design before starting implementation.

Completion criteria

  • The agreed policy is consistent for pointer, array, nested generic and ordinary named generic types.
  • Accepted compact/spaced forms have equivalent AST/HIR, or intentionally rejected forms identify the exact boundary with actionable help.
  • Genuine comparison/shift operators retain maximal-munch expression behavior; human/JSON source ranges remain accurate.
Lenguaje dominante
Rust
Estrellas
56
Forks
21
Merge medio
23 h 20 min
PR fusionados (30 d)
45

Preparar el entorno

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 wavefnd/Wave

Todos los issues de wavefnd/Wave

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.