Pular para conteúdo

AUR-474 — Funcao de uma linha e uma funcao

Documento histórico do board. Pode descrever componentes removidos; para uso atual, consulte o guia do produto.

Defeito medido (revisao adversarial do AUR-464)

#!/bin/bash

# Greets a name.
greet() { echo "hello $1"; }

A pagina gerada nao continha ### function greet: bashKeywordPattern e bashParenPattern em internal/documentation/extractors/bash/extractor.go so reconheciam uma declaracao cujo corpo abre em linha propria (name() { com nada apos o { alem de espaco). Uma declaracao cujo {, corpo e } inteiros estao na MESMA linha fisica nunca casava a regex.

O efeito era duplo: alem de perder a funcao como simbolo, o comentario que a precedia ("Greets a name.") caia em ## Script Notes como se fosse nota solta do arquivo — o leitor via um paragrafo falando de uma funcao que a pagina nao lista.

Correcao

bashKeywordPattern e bashParenPattern agora compartilham uma cauda comum (bashBodyTail) que aceita, apos o nome (e, na forma POSIX, apos ()), exatamente tres formas:

  1. nada — o { de abertura fica em outra linha (forma ja reconhecida);
  2. um { sozinho no fim da linha (mesmo caso, so que o { calha de estar na linha da declaracao);
  3. {, um corpo de uma linha, e um } que fecha a linha (com espaco em branco final permitido) — o alvo deste card.

A ancora de nome continua exigindo que o proprio identificador seja seguido imediatamente (so espaco permitido) por ( (forma POSIX) ou que venha logo apos a palavra-chave function — nada nessa ancora mudou. E essa ancora, nao o final da linha, e o que ja excluia (e continua excluindo) my-array=() e x=$(cmd): o caractere logo apos o nome nunca e ( nesses casos, entao a tentativa de casamento nem comeca.

Isto NAO e um parser de Bash: .* entre { e o } final e guloso e nao balanceia chaves aninhadas. O alvo declarado e apenas a forma de uma linha inteira nome() { ... } (e as variantes function nome { ... } / function nome() { ... }), nao qualquer corpo com chaves internas.

PowerShell

powerShellFunctionPattern (^\s*function\s+([A-Za-z_][A-Za-z0-9_.-]*)\b) ja nao ancora o fim da linha: ela so exige function Nome no inicio, sem exigir nada especifico sobre o que vem depois. Confirmado com um teste descartavel: function Greet { Write-Host "hi $Name" } e function Greet($Name) { Write-Host "hi $Name" } ja casam hoje, sem qualquer mudanca de codigo. O defeito e exclusivo do extrator Bash; nenhuma mudanca foi feita em internal/documentation/extractors/powershell.

AC-002 — o que continua nao sendo simbolo

  • my-array=() — nome seguido de =, nunca de ( diretamente: a ancora de nome nao caza.
  • x=$(cmd) — mesma razao (nome seguido de =, nao de ().
  • if [ ... ]; then ...; fi numa linha — nao comeca com nome( nem com function nome; a linha inteira nunca alcanca a ancora inicial.
  • Uma string contendo foo() { } dentro de aspas, ex. echo "foo() { }" — a linha comeca com echo, nao com foo(; a ancora ^\s*NOME\( exige que o nome esteja no INICIO da linha (so espaco em branco antes), entao o texto entre aspas no meio da linha nunca e candidato.

AC-003 — a tabela do AUR-464 sobrevive

A regra de associacao de comentario (conjuncao de tres sinais: primeiro simbolo da pagina, nenhuma nota resolvida ainda, nenhum codigo executado antes) nao foi tocada. O que mudou e exclusivamente o que matchBashFunction aceita como declaracao de funcao — o mesmo simbolo, uma vez reconhecido, segue as mesmas regras de doc/nota de sempre. bash tests/acceptance/AUR-464.sh AC-001 permanece exit 0 antes e depois desta mudanca, incluindo as duas mutacoes MUT-001/MUT-002 daquele card.