Um type checker de Ruby que já achou 15 bugs no Discourse, no Rails, no Zammad e no ruby-lsp

Depois que o PR está aberto, o que decide se ele avança não é o patch. São três portões, medidos, não sobre a ferramenta.

O CLA da Shopify pede assinatura humana mais um comentário que case o regex do workflow. Meu primeiro comentário, "CLA signed.", passou o if do workflow, o job concluiu success, e o log dizia Comment does not match CLA pattern: run verde não significa portão vencido. O que funcionou foi "I have signed the CLA."

action_required é aprovação de workflow pra primeira contribuição, por repositório: trava o zammad (5 PRs) e o ruby-lsp (1). Rails e Discourse não têm essa trava.

No GitLab, cota e membership impedem até o push: por isso 6 MRs prontos seguem não abertos.

Nenhum dos três portões tem a ver com a qualidade do patch, e nenhum aparece antes do PR estar aberto.

Um apontamento de checker é hipótese, não bug. Todo item desta lista passou por prova de dois lados no arquivo real do repositório: roda e falha antes do conserto, roda e passa depois. Reproduzir num arquivo separado não vale, porque isso testa o meu entendimento do código, não o comportamento do projeto.

Nos casos de remoção de código morto a exigência é outra: provar que ninguém alcança aquele código. Isso significa varredura no repositório inteiro, incluindo despacho dinâmico (send, public_send, respond_to?, method_missing, delegate) e as subclasses da classe, não só quem chama direto. Foi essa última parte que quase escapou no #58569 do Rails: a classe tem duas subclasses, e se qualquer uma delas chamasse o método a história mudava de limpeza para bug real.

O formato dos PRs também não saiu de gosto pessoal. Saiu de medição do que o projeto já aceitou. Contei primeiro os cem últimos merges do Rails, não achei nenhuma remoção de código morto e concluí que não havia precedente. Cem merges no Rails cobrem duas semanas: a busca no histórico inteiro mostrou uma campanha de doze PRs de remoção mergeados um mês antes. Amostra curta não mede categoria rara.

Aceitação também não é sempre a mesma coisa. No Zammad o desenvolvimento real acontece num GitLab interno; o GitHub é espelho, e o merge nativo por lá está parado desde 2021. Quando o mantenedor aceita um fix, ele aplica o patch como commit à mão e fecha o PR citando o hash. Por isso a lista distingue mergeado de aplicado por commit: dois jeitos de dizer sim, sem esconder qual foi qual.

O #58566 do Rails é o caso mais completo da seção: fechado sem merge, com um comentário só, de byroot (Jean Boussier, do core do Rails): "If it's never called, let's just remove the method entirely." Não foi recusa do achado, foi recusa da forma: eu mandei correção pra um método que estava morto, quando o certo era remoção. Classifiquei o método como alcançável sem provar. A prova, feita depois: @thread_query_caches aparece em exatamente dois lugares no repositório, a instanciação e uma chamada a compute_if_absent; .clear nunca é chamado. E o corpo do método chamava synchronize num objeto que não tem esse método, então levantaria erro se alguém chamasse: morto e quebrado, e eu mandei consertar em vez de remover. O desfecho é o estado aplicado por commit: ele mesmo removeu o método no commit 22a02ee12e , mensagem literal:

Get rid of `QueryCacheRegistry#clear`

The method is dead code.

Com crédito de coautoria pro achado. Entrou, só não pela minha branch.

No #58568 do Rails, o próprio método que o itaruby apontou não tinha teste nenhum na suíte. A prova inicial de que o código era morto veio de um grep 'def expr' no repositório, que jamais acharia um attr_accessor :expr. O instrumento certo era seguir a cadeia de herança, não grepar pelo nome do método. O erro foi corrigido antes do PR sair, e o teste que faltava entrou junto.

O #42898 do Discourse mostra o mesmo tipo de falha com consequências opostas, no mesmo arquivo do importador de Lithium: Dois crashes no importador de Lithium. Um file.unlind que não existe em Tempfile, engolido pelo rescue em volta, vazando um arquivo temporário por avatar importado. E um link_post_uploads chamado no CookedPostProcessor, que não tem esse método: esse não é engolido e derruba o pós-processamento de anexos inteiro.

Três achados do Zammad (#6329, #6331, #6332) vieram com spec de regressão que a suíte não tinha. Nos três o conserto de produção é uma linha; o resto do diff, entre treze e quatorze linhas, é teste.

O que está provado: o itaruby não exige nada, e lê RBS inline se você tiver. Sem configuração, sem passo de adoção. Os 14 bugs desta página saíram de 3 repositórios com zero sorbet/, zero .rbi e zero extend T::Sig: 13 envios, 7 aceitos. O repositório restante do corpus, ruby-lsp, roda Sorbet e tem seu próprio bug, na próxima seção.

Nota de escopo: de bloco sig do Sorbet, o itaruby aproveita o tipo de retorno; não aproveita o tipo de parâmetro. A sig já fala retorno, falta ela falar parâmetro. Isso importa menos do que parece, porque o corpus quase não usa sig. Testei: uma classe com extend T::Sig e sig { params(n: Integer).returns(String) }, chamada passando String onde a assinatura pede Integer no parâmetro, não gera diagnóstico nenhum: é exatamente o lado que ainda falta. Mas rails, discourse e zammad têm zero sig. O ruby-lsp, o repositório mais tipado do corpus, tem zero sig real em produção: o texto sig que sobra no repositório é comentário de documentação e fixture de spec, não anotação. O tapioca tem um, em lib/.

Existe uma razão mais afiada por trás daquele zero, e ela é o comportamento documentado do próprio Sorbet, não uma opinião sobre ele. Arquivo sem sigil cai em # typed: false por padrão, e nesse nível o Sorbet reporta só sintaxe, resolução de constante e correção de sig. O manual dele é explícito: o nível "apenas impede que o corpo daquele método seja verificado". Então num repositório sem anotação o Sorbet não está falhando em achar esses bugs: ele nunca é convidado a olhar. É essa a lacuna inteira que o itaruby ataca, e é por isso que a comparação é sobre alcance, não sobre velocidade. sorbet.org/docs/static

O que muda a leitura: o itaruby lê RBS inline. É a anotação que o próprio time do tapioca passou a usar no código de produção do ruby-lsp, em vez de sig: um comentário de uma linha em cima do método, no formato #: (Tipo) -> Tipo. Testei o mesmo método nas três formas de anotar:

# sem anotação
def formata(n)
  n.to_s
end
formata("7")
# itaruby: silêncio (correto, não tem de onde saber)

# com RBS inline
#: (Integer) -> String
def formata(n)
  n.to_s
end
formata("7")
# itaruby: p1.rb:7:18: error[E0103]: argument 1 of 'formata' expects Integer, got String

# com sig do Sorbet
extend T::Sig
sig { params(n: Integer).returns(String) }
def formata(n)
  n.to_s
end
formata("7")
# itaruby: silêncio

O contraste de custo é o dado mais forte da seção. Pro Sorbet enxergar as dependências, ruby-lsp e tapioca mantêm 754.669 linhas de .rbi vendorizado (246.830 + 507.839), mais gem de runtime, mais sigil por arquivo, mais passo de geração. RBS inline não pede nada disso: é um comentário em cima do método, zero arquivo vendorizado, zero gem de runtime, zero geração.

RBS de core/stdlib, em arquivo separado, não inline: não consome. RBS de gem via rbs collection, também em arquivo separado: não consome. RBI não é falta de cobertura, é busca: declaração dentro de .rbi escrita como bloco aninhado indexa certo, o caminho completo existe no índice; quem falha é a consulta, que procura pelo caminho qualificado num mapa onde esse nome foi registrado sem qualificação, e desiste antes de aplicar o refiltro que existe justamente pra isso. Só a forma compacta module X::Y evita o problema. É o mesmo bug que explica por que a correção de alias curou o ruby-lsp e não o tapioca, na seção "O ciclo" logo abaixo.

Esta tabela mudou desde a publicação original desta página: o ruby-lsp caiu de pior pra melhor do corpus depois de uma correção no próprio itaruby, não no código escaneado. O mecanismo e a previsão verificada estão na seção "O ciclo", logo depois de "Cara a cara com o Sorbet".

O que fica de pé, antes e depois da correção: nem "pior" nem "melhor" mediam tipagem. Mediam o quanto o itaruby ainda tinha bug de parsing específico de repositório. O contrato que sobra não é "funciona melhor com mais tipo": é sem exigência nenhuma, e lê RBS inline quando o código já tiver.

O teste mais duro que dá pra fazer: rodar o itaruby contra o Sorbet nos dois únicos repositórios do corpus exploratório que já adotaram Sorbet de verdade. srb tc global, sem bundle install, nos dois:

As quatro medições de tempo são da mesma sessão, mesma máquina, três execuções cada, mediana. O Sorbet é 2,9x mais rápido no ruby-lsp e 2,7x no tapioca. Tempo de parede não é comparável entre sessões diferentes nesta página: numa remedição anterior o ita check no ruby-lsp deu 445ms; nesta, 496ms, sem nenhuma mudança de binário entre as duas. Variação de sessão pra sessão de 10% a 20% nesta máquina, o que inviabiliza qualquer leitura de "a correção custou tempo" sem uma medição antes/depois feita na mesma rodada.

A contagem de arquivos difere porque o srb aplica os --ignore do sorbet/config do projeto (fixtures, vendor) e conta os .rbi junto; o itaruby conta os .rb crus e não tem lista de ignore equivalente.

O Sorbet está verde nos dois: saída literal No errors! Great job.. O itaruby, no mesmo código, produz 111 diagnósticos brutos. Não achei 111 bugs. Classifiquei os dois conjuntos inteiros, item por item, não uma amostra:

srb tc continua em zero erro nos dois.

Um número melhorou e o outro piorou, e os dois valem o mesmo destaque: na amostra de 10 do ruby-lsp lá em cima, 7 de 10 eram falso positivo (70%); na classificação exaustiva de 51, caiu pra 31%. O tapioca foi na direção contrária: virou o repositório com a maior proporção de falso positivo do corpus, 57%. Não foi estado terminal: a causa tinha nome, endereço no código, e a correção entrou. O resultado está na seção "Wave 8" logo abaixo: tapioca caiu de 17 para 1, teto documentado, não reclassificação a zero.

Reconferi os 10 itens originais do ruby-lsp contra a classificação exaustiva: 2 desapareceram (eram falso positivo, resolvidos pela correção de alias), 8 permanecem, e 1 desses mudou de classificação porque a evidência anterior tinha conferido o diretório errado. Erro de medição nosso, não da ferramenta.

Os falsos positivos têm causa. A primeira vez que medi essa causa o número saiu errado; a versão corrigida está abaixo. Reclassifiquei os 41 avisos de constante que sobraram no ruby-lsp depois da correção de alias, por mecanismo:

As duas alavancas de tipo, RBI já commitado e RBS de core/stdlib do disco, são quase do mesmo tamanho: 11 contra 9. Nenhuma sozinha resolve metade dos 41. Não existe fonte de tipo salvadora aqui: é sempre as duas juntas, e mesmo as duas juntas não cobrem tudo.

11 dos 41 são fixture: constantes falsas que o próprio ruby-lsp define de propósito pra testar seu detector de erro de sintaxe. O sorbet/config do projeto exclui essa pasta via --ignore; o itaruby não honra esse --ignore. Isso é 27% do que sobrou sendo o itaruby reportar sobre arquivo que o dono do projeto já declarou fora do escopo, uma limitação concreta e verificável.

Sobre o método, porque ele é a base de todo número desta página: a primeira medição desse mecanismo tinha dois erros. O denominador original, 160 constantes únicas não resolvidas, caiu para 29 assim que as causadas por alias saíram da lista com a correção do commit 7d3a781. E o numerador original, 78, também estava errado: o regex casava constante por sufixo do nome, não pelo caminho completo, então nomes como A e C entravam na conta por terminarem igual a uma declaração real de T.let em outro lugar do arquivo. Os dois erros só apareceram quando troquei grep por consulta direta à API do RBS, carregando as 61 bibliotecas de stdlib e perguntando por nome de tipo em vez de por texto. O número certo, depois disso, é o da tabela acima: 11 de 41, 27%. A troca de grep por API resolveu o erro de sufixo, mas não bastou sozinha: a consulta aceitava um atalho, nome de topo existindo já contava como achado, então Gem existir bastava pra Gem::DefaultUserInteraction passar, quando a única ocorrência real dessa constante em todo o RBS é um comentário. A lição completa não é "API em vez de texto": é que a pergunta tem que ser pelo caminho exato, porque aceitar prefixo é grep de sufixo vestido de API.

Os 7 diagnósticos do ruby-lsp que não são aviso de constante têm partição completa, verificada na fonte, não amostra:

O caso de code_action_resolve.rb:435 merece linha própria: o cast #: as !nil colado no end da linha 417 é lido certo, isso está confirmado. O que falta é estreitar o tipo antes de o cast chegar: as linhas 410 a 417 são um case @code_action[:title] com três when e sem else, e sem esse ramo o tipo que sobra é String | nil. O cast não é ignorado: ele é aplicado sobre um tipo que já chegou errado.

Nem toda linha da tabela é bug. Estreitamento de case sem else é família declarada fora de escopo por decisão, fronteira escolhida, não falha à espera de descoberta. O genérico [T] tratado como tipo fixo é bug real, e é a terceira vez que esse mecanismo aparece nesta investigação: já tem correção priorizada. O cast #: as untyped ignorado segue sem correção.

O enquadramento que fecha esta seção: o valor está em código NÃO tipado. Nos 3 repositórios sem tipagem o funil deu 14 bugs reais, 13 envios, 7 aceitos. Nos dois repositórios com Sorbet, o Sorbet já está verde e o itaruby produz majoritariamente falso positivo. Isso é escopo, não derrota: onde já existe Sorbet configurado e verde, o itaruby hoje não acrescenta, atrapalha.

Único bug real que o itaruby achou nos dois repositórios com Sorbet, num achado em 111 diagnósticos brutos nesses dois repositórios. Não é vitória, é a exceção que confirma o escopo. O bug: um raise AbstractMethodInvokedError dentro de module RubyIndexer quando a constante só existe como RubyLsp::AbstractMethodInvokedError, módulo irmão, não ancestral. O raise nunca resolve; reproduzi a estrutura separada e confirmei: sobe NameError. Dos 17 sítios desse mesmo raise no repositório, 16 estão em lib/ruby_lsp/ e resolvem certo; só esse está fora do namespace certo. É guarda defensiva latente, não crash em produção, porque as duas subclasses concretas já implementam o método abstrato. O PR está aberto, #4197 , no ruby-lsp: 2 linhas adicionadas , nenhuma removida. Contribuição de fora da Shopify passa por dois portões antes de virar código: o CLA da empresa e a aprovação de workflow de primeira contribuição, os dois pendentes agora.

O dado mais interessante da seção: esse bug estava num repositório que roda Sorbet em CI, verde, e o Sorbet não pega porque a flag --enable-experimental-rbs-comments do sorbet/config do próprio projeto silencia esse tipo de guarda. Não é "o itaruby é mais forte que o Sorbet": é uma flag de configuração que criou um ponto cego, e uma ferramenta que não lê a configuração do projeto passou por ele sem saber que existia. É o argumento real a favor de rodar duas ferramentas diferentes em vez de uma.

Sobreposição entre os dois conjuntos de erro real: zero. Não é achado, é ausência de dado: o conjunto do Sorbet nos dois repositórios é vazio, então não existe interseção pra medir. Não é vitória, é grau de liberdade zero na comparação.

A tabela de taxa lá em cima mostrou o ruby-lsp em 1240 diagnósticos por mil arquivos, o pior do corpus, sendo o repositório mais tipado. Contraintuitivo o bastante pra valer investigar a causa em vez de aceitar o número.

A causa tem nome e linha, em lib/ruby_lsp/utils.rb:6-7:

Interface = LanguageServer::Protocol::Interface
Constant = LanguageServer::Protocol::Constant

O itaruby não seguia esse tipo de alias de constante; toda referência a Interface::X ou Constant::X no resto do arquivo virava diagnóstico de constante não resolvida. Isso respondia por 405 dos 449 avisos de constante do repositório.

Previsão feita antes de tocar no código: cerca de 405 avisos deveriam desaparecer com a correção. Depois da correção, commit 7d3a781: 408 desapareceram. Erro de previsão de 0,7%.

Essa conclusão saiu de comparar totais por repositório, antes e depois, e comparação de totais não estabelece afirmação sobre conjunto: eu mesmo cometi esse erro depois, na wave 7, onde o total do rails ficou idêntico entre duas waves, 2316 contra 2316, escondendo 5 diagnósticos saindo e 5 entrando. O diff no nível de conjunto desta correção de alias nunca foi rodado, e não tenho mais o binário daquela wave pra rodar agora: não sei dizer se algum diagnóstico novo apareceu em algum lugar do corpus.

Medido no commit 7d3a781, mesma contagem de arquivos de antes.

O que sobrevive dessa comparação é a magnitude, não o conjunto: os repositórios sem tipagem quase não se moveram, deltas líquidos de rails -48, discourse -75, zammad -12, enquanto o repositório tipado caiu 405 (delta líquido também). Se o ganho tivesse vindo espalhado por igual, seria motivo de desconfiança: um fix genérico que reduz ruído em todo lugar por igual não prova mecanismo nenhum. Aqui o ganho ficou exatamente onde o mecanismo previu que ficaria.

Por que a correção curou o ruby-lsp e deixou o tapioca intacto, os dois com o mesmo tipo de alias? Isolei com um teste de 9 linhas, três variações do mesmo alias mudando só onde o alvo é declarado:

Em arquivo .rbi, declaração escrita como bloco aninhado indexa certo: o caminho completo existe no índice. Quem falha é a consulta, que procura pelo caminho qualificado num mapa onde esse nome foi registrado sem qualificação, e desiste antes de aplicar o refiltro que existe justamente pra isso. Só a forma compacta evita o problema. Em .rb as duas funcionam. As duas linhas reais, lado a lado:

# ruby-lsp, lib/ruby_lsp/utils.rb:7 (alias num .rb, curado)
Constant = LanguageServer::Protocol::Constant

# tapioca, sorbet/rbi/gems/ruby-lsp@0.26.10.rbi:2380 (alias num .rbi, não curado)
RubyLsp::Constant = LanguageServer::Protocol::Constant

A diferença entre os dois repositórios não é perfil de código, é um bug de indexação com endereço. E a consequência que interessa a quem lê: consertar isso não é aumentar cobertura, é derrubar falso positivo no repositório onde a ferramenta parece pior.

A reclassificação fechou, exaustiva, item por item, não amostra de 20. Isso substitui a leitura provisória de "não decidido" que eu tinha deixado aqui: no ruby-lsp, falso positivo caiu de 70% (7 de 10, amostra antiga) para 31% (16 de 51, contagem completa); no tapioca foi na direção contrária e virou o repositório com a maior proporção de falso positivo do corpus, 57% (34 de 60). srb tc segue em zero erro nos dois. A frase de duas horas atrás, "onde já existe Sorbet configurado e verde, o itaruby hoje não acrescenta, atrapalha", não serve mais como frase única pros dois repositórios: no ruby-lsp ficou mais fraca, falso positivo já é minoria (31%); no tapioca ficou mais forte, falso positivo é maioria clara (57%), e não foi estado terminal: a causa era o bug de indexação de .rbi acima, tinha endereço no código, e a correção entrou. O resultado está na seção "Wave 8": tapioca caiu de 17 para 1, teto documentado.

Wave 8 substitui a wave 7 como retrato atual: binário compilado do commit 5c5c8c3, 2026-08-26, mesmas árvores fixadas por sha de antes. Composição por código de diagnóstico, os seis repositórios do corpus:

O chatwoot teve sua primeira medição na wave 7. Esta é a primeira comparação que existe pra ele: o diff de conjunto silenciou 2 diagnósticos, zero novos.

Dos 30 do ruby-lsp, 3 são E0001 (erro de sintaxe) em test/fixtures/syntax_diagnostics.rb e test/fixtures/multiple_invocations.rb , arquivos que são Ruby inválido de propósito, escritos pro próprio ruby-lsp testar diagnóstico de sintaxe. O checker está certo ali: não é acerto contra bug real, é reconhecer fixture proposital como o que é.

O tapioca, que esta página classificou como 60 diagnósticos, 0 bug real e 34 falso positivo (57%, o pior do corpus em proporção), caiu para 1. Não é tapioca limpo: sobrou 1, e é teto documentado. O autor diz que esse restante é um caso onde INSTANCE é valor, limitação conhecida e não defeito aberto.

Trajetória dos dois repositórios tipados, quatro rodadas de medição: ruby-lsp 456 -> 51 -> 31 -> 30; tapioca 60 -> 60 -> 17 -> 1.

Diff de conjunto entre wave 7 e wave 8, chaveado por caminho, linha, coluna e código:

Zero diagnóstico novo nos seis repositórios do corpus. Dessa vez a afirmação está estabelecida por diff de conjunto, não por soma de totais, que é exatamente a diferença que a seção "Comparar totais não é comparar conjuntos" denuncia. Onde esta página já disse que essa afirmação não tinha sido estabelecida pra alguma wave, ela continua verdadeira pra aquela wave: é aqui, na wave 8, que ela passou a ser estabelecida.

A chave do diff ganhou uma coluna, e essa é uma correção da própria regra que esta página publica. A seção "Comparar totais não é comparar conjuntos", logo abaixo, diz que o diff deve ser chaveado por arquivo, linha e código, nunca por mensagem. Essa regra estava incompleta: arquivo:linha:código não distingue dois diagnósticos do mesmo código na mesma linha, e existem pares reais assim no discourse. Chavear sem coluna faz esses pares parecerem silenciados quando os dois continuam sendo acusados corretamente. A chave certa inclui a coluna: arquivo:linha:coluna:código.

A maior parte da queda do discourse, 1658 , é a raiz única já contada na seção abaixo: 1642 desses são o DB escrito com cbase. O resto, 16 , é guarda defined?.

A wave 7 foi declarada sem drift pelo autor do checker. Remedi, 5c5c8c3, e o que parecia 4 falsos positivos isolados eram duas raízes com 1675 sítios ao todo, não quatro casos, uma delas com ordem de grandeza muito maior do que a primeira leitura sugeria.

Raiz 1, escrita de constante de topo com cbase: 1645 sítios em 3 repositórios.

Quando o código escreve uma constante de topo na forma com cbase, ::X = valor, essa constante nunca entrava na tabela de constantes de topo. Segundo lado do mesmo defeito: a checagem de existência chaveava o fallback de cbase pelo nome não trimado.

Raiz 2, guarda defined?: 30 sítios em 3 repositórios.

Acusar o argumento de defined? nunca foi o problema: isso o checker já fazia certo. O falso positivo real era ler a mesma constante no ramo então do if ou do ternário, o ramo que só executa quando ela existe. Idioma de dependência opcional: AppBuilder, PluginBuilder, ENGINE_ROOT, Nokogiri::HTML5, MiniProfiler, RailsFailover, WebPush, Facebook::Messenger::Subscriptions. A regra que consertou tem controle dos dois lados: leitura no ramo senão continua sendo acusada, porque ali ela é insegura de verdade, e defined?(X) guardando leitura de Y continua acusando Y.

O maior nome único do corpus inteiro não era constante de gem faltando declaração: era um bug de indexação nosso. Uma linha de código do discourse gerava 1642 diagnósticos falsos.

As duas raízes foram consertadas na wave 8, binário compilado do commit 5c5c8c3, e verifiquei o conserto por rodada minha:

A prova do outro lado, que separa consertar de suprimir: as constantes que são de gem de verdade continuam sendo acusadas. ::Trilogy segue em 3 no rails/rails, sem mudança. Além disso, zero diagnóstico novo nos seis repositórios, e dessa vez essa afirmação está estabelecida por diff de conjunto, não por comparação de totais.

Vale publicar como verificação, não elogio: a atribuição que o autor mandou (cbase contra guarda defined?) soma exatamente com os totais que medi de forma independente, repositório por repositório:

Duas contagens feitas por caminhos diferentes fecharam no mesmo número, repositório por repositório. É o oposto do caso da wave 7, onde a composição não fechava com o total e sobravam 3.

O achado de método que motivou essa checagem: comparar totais não é comparar conjuntos. No rails, o total ficou idêntico entre as duas waves, 2316 e 2316, e por dentro 5 diagnósticos saíram e 5 entraram: um delta líquido zero escondia 10 itens se movendo.

Pior: se o diff fosse chaveado pela mensagem em vez de por arquivo:linha:código, o rails teria acusado 187 mudanças, porque a wave 7 passou a imprimir o nome da constante na forma absoluta (::WebSocket::Driver em vez de WebSocket::Driver) e todo diagnóstico mudou de texto sem mudar de sítio. Número grande e falso é mais perigoso que número pequeno e certo.

O valor de medir por conta própria não é desconfiar do outro: é que delta líquido e reescrita cosmética escondem coisa em direções opostas.

A própria página cometeu esse erro na seção da correção de alias, mais acima: a passagem foi corrigida, não apagada.