CodeQL 2.27.2 quebra consultas Go — a migração do CFG exige revisão

|Autor: Equipe editorial da QUASA|6 min de leitura
CodeQL 2.27.2 quebra consultas Go — a migração do CFG exige revisão

O GitHub anunciou a disponibilidade do CodeQL 2.27.2 em 9 de outubro de 2026 e destacou uma mudança incompatível na biblioteca de Go. A implementação do grafo de fluxo de controle, ou CFG, foi reescrita. Consultas personalizadas que dependem das APIs ou da forma anterior do grafo podem deixar de compilar ou produzir achados diferentes depois da atualização.

A análise do WindowsForum, publicada também em 9 de outubro, identifica a reescrita como uma mudança relevante para autores de consultas Go. A revisão tem duas frentes: referências a símbolos e tipos alterados, que podem causar erros de compilação, e suposições sobre nós, arestas e blocos básicos, que podem mudar resultados mesmo quando a consulta compila.

Por que a forma do CFG de Go mudou

O changelog técnico da versão, datado de 7 de outubro de 2026, registra que o CFG de Go passou a usar a biblioteca compartilhada de fluxo de controle. O grafo inclui nós adicionais para atribuições, parâmetros e resultados de funções, instruções range e chamadas adiadas com defer. Ele contém apenas nós alcançáveis a partir do ponto de entrada, e os blocos básicos agora são construídos diretamente sobre essa implementação compartilhada.

Essas diferenças importam quando uma consulta usa a estrutura do CFG como parte da regra. Uma condição que percorre uma sequência específica de arestas pode seguir outro caminho; uma regra que conta nós ou exige uma localização específica pode selecionar outro elemento para o mesmo código Go. Também mudam potencialmente a representação textual dos nós e os pontos em que começam e terminam os blocos básicos. Assim, uma diferença nos achados após a atualização exige examinar a lógica da consulta antes de ser atribuída a uma alteração no programa analisado.

APIs que podem interromper uma consulta

Identificadores de consultas Go mostram a substituição indicada para IfStmt.getCond e a ausência de BasicBlocks::Cfg.

A primeira triagem deve separar remoção, mudança de tipo e obsolescência. Elas pedem respostas diferentes: uma referência a uma classe removida precisa ser adaptada; um tipo de retorno mais amplo exige revisar as restrições da consulta; um método obsoleto ainda existe nesta versão, embora já tenha um substituto indicado.

  • BasicBlocks::Cfg foi removida. Consultas ou bibliotecas QL que referenciam essa classe precisam ser adaptadas à implementação de blocos básicos agora usada diretamente por BasicBlock. Essa é a referência mais clara para procurar uma incompatibilidade de símbolo.
  • ControlFlow::EntryNode e ControlFlow::ExitNode foram adicionados. ControlFlow::entryNode e ControlFlow::exitNode passam a retornar esses tipos mais específicos. Vale examinar predicados e declarações que dependem dos tipos anteriormente esperados.
  • IfStmt.getCond foi marcado como obsoleto, e IfStmt.getCondition é o substituto indicado. A troca é uma tarefa de migração, mas a obsolescência, por si só, não significa que o método tenha sido removido nesta versão.
  • Os tipos de retorno de IfStmt.getThen e LoopStmt.getBody foram ampliados de BlockStmt para Stmt. Uma consulta que exige especificamente BlockStmt precisa revisar essa restrição e o uso que faz do valor retornado.
  • SwitchStmt.getExpr foi adicionado como acesso comum à expressão examinada por switches de expressão e de tipo. É uma nova opção da biblioteca, não uma chamada antiga que toda consulta precise substituir.
  • Na representação intermediária, classes como ReadArgumentInstruction, InitResultInstruction, IncDecInstruction, EvalIncDecRhsInstruction, EvalImplicitOneInstruction, SelectInstruction e SendInstruction foram removidas ou consolidadas. EvalCompoundAssignRhsInstruction passou também a representar incrementos e decrementos; ela e EvalImplicitInitInstruction representam diretamente as escritas associadas.

A presença de um nome na lista não prova que toda consulta que o menciona falhará. O efeito depende de como o símbolo é usado e das bibliotecas importadas. Por isso, procurar apenas no arquivo principal da consulta deixa de fora módulos QL locais e predicados auxiliares compartilhados pelo pacote.

Como localizar dependências do CFG antigo

Uma função Go revela caminhos e localizações de análise diferentes após a revisão do CFG no CodeQL 2.27.2.

Uma busca no pacote personalizado pode começar pelos identificadores alterados: BasicBlocks::Cfg, as classes de instrução intermediária listadas acima, getCond, getThen, getBody, entryNode e exitNode. Depois, é preciso ler cada ocorrência no contexto. Os nomes de predicados, isoladamente, apontam lugares para inspeção; não permitem concluir que todos estejam quebrados.

Há uma segunda busca, menos mecânica, para regras que dependem da topologia do grafo. Merecem atenção predicados que contam nós, comparam sua forma textual, fixam localizações, presumem uma ordem de arestas ou associam um resultado à fronteira de um bloco básico. Essas dependências podem estar escondidas em funções auxiliares e não mencionar nenhuma API removida. Uma consulta que continua compilando ainda pode expressar uma regra diferente quando o conjunto de nós alcançáveis e a divisão em blocos mudam.

O que comparar antes da atualização

Para equipes que mantêm consultas próprias, a verificação pode seguir uma sequência curta. Trata-se de uma recomendação de migração baseada nas mudanças documentadas, não de um resultado de teste desta publicação.

  1. Faça o inventário das consultas Go e das bibliotecas QL locais que elas importam. Localize referências às classes removidas ou consolidadas e aos métodos e tipos alterados.
  2. Compile as consultas com o CodeQL 2.27.2. Resolva primeiro erros de símbolo e de tipo; trate IfStmt.getCond como uma substituição recomendada, sem confundir seu aviso de obsolescência com uma remoção.
  3. Execute as consultas sobre uma base de código Go conhecida e compare os achados com os da versão anterior. Examine a quantidade de resultados, as localizações e os caminhos que levaram a cada achado quando a regra usa o CFG.
  4. Na análise das diferenças, dê atenção a atribuições, parâmetros e resultados, range, defer e trechos inalcançáveis. São construções diretamente afetadas pela nova representação ou pelo critério de alcance a partir da entrada.

A compilação verifica se as referências de API continuam válidas. A comparação dos achados responde à outra questão: se a regra ainda seleciona os trechos pretendidos após a mudança de nós, arestas e limites de blocos. Uma contagem igual de resultados também pode ocultar mudanças de localização ou de caminho.

Uma melhoria de cobertura que não pede migração do CFG

A versão também amplia os modelos de Go para reconhecer o caminho de importação github.com/coder/websocket, além de nhooyr.io/websocket. Essa mudança pode ampliar a cobertura de análises que usam o pacote, mas não é uma substituição de API do CFG. Para quem mantém consultas próprias, a decisão sobre a atualização depende sobretudo da compilação do pacote e da comparação de seus achados: referências removidas aparecem cedo; dependências da forma antiga do grafo podem aparecer apenas no resultado.

Leia também:

Compartilhar:

Assine nossa newsletter

Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.

0