Aaronontheweb / Aaronontheweb/ShellSyntaxTree

Extract shared native argument fragment classification

Aperta
#69 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Lingua principale
C#
Stelle
15
Fork
0
Merge medio
9m
PR unite (30g)
7

Descrizione

Problem

PR #68 added equivalent native-argument fragment walks to the Bash and PowerShell parsers. Both implementations now collect contiguous lexer fragments, preserve the complete raw span and decoded value, detect opaque fragments, and safe-fail resolver-sensitive mixed quoting. Keeping those rules duplicated creates a drift risk when another fragment shape or shell is added.

This is not a request for a shared lexer or parser core. Bash and PowerShell must retain their shell-specific tokenization, quoting, recursion, and command semantics.

Proposed scope

Extract an internal shell-neutral classification result for one native argument assembled from parser-owned lexer fragments. Each parser adapts its own tokens into the helper and remains responsible for consuming the resulting token range.

The shared result should carry:

  • the complete authored source span and raw value;
  • the combined decoded logical value;
  • whether any fragment is opaque or computed;
  • whether all value fragments are literal;
  • whether mixed literal and expandable fragments contain resolver-sensitive syntax;
  • the first index after the consumed fragment run.

Non-goals

  • Unifying the Bash and PowerShell lexers.
  • Building a shared parser base class.
  • Changing the public AST or parser APIs.
  • Weakening DynamicSkip behavior for ambiguous mixed quoting.

Acceptance criteria

  • Bash and PowerShell use one internal fragment-classification implementation.
  • Shell-specific token adapters remain small and explicit.
  • Existing Raw, Value, source-span, path, and DynamicSkip behavior remains unchanged.
  • The PR #68 adversarial corpus cases for quoted values, maximal fragment runs, unquoted prefixes, mixed literal syntax, and curl @ transformation remain green in both shells.
  • dotnet build -c Release, dotnet test -c Release, and header verification pass.

Extraction trigger

Do this before adding a third shell or another native fragment rule. Until then, the current duplication is correct but carries maintenance cost.

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Confronta le scansioni dei frammenti degli argomenti nativi di Bash e PowerShell introdotte da PR #68, quindi esamina i relativi casi del corpus avversariale per valori quotati, sequenze massime, sintassi mista e trasformazione di curl @. Estrai solo la classificazione shell-neutral, mantenendo separati gli adattatori dei token e il comportamento del parser. Esegui dotnet build -c Release, dotnet test -c Release e la verifica degli header; il lavoro è terminato quando tutto il comportamento esistente continua a essere verde in entrambe le shell.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
bash, csharp, powershell
Ambito
tooling
Tipo di issue
Refactoring
Difficoltà
4/5
Tempo stimato
3-5 giorni
Stato di attività
Tranquilla
Chiarezza
Abbastanza chiara
Idoneità per principianti
48/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.