La documentación de `golang.org/x/tools/go/analysis` de Go define una interfaz para el análisis estático modular: los analizadores inspeccionan un paquete de Go cada vez, notifican diagnósticos y pueden intercambiar resultados mediante una API común. El framework está diseñado para que el mismo analizador pueda incorporarse a herramientas de línea de comandos como `vet`, editores, IDE, sistemas de compilación, frameworks de pruebas, herramientas de revisión de código y pipelines por lotes más amplios.
El primer párrafo presenta la interfaz de análisis de paquetes de Go; esta marca oficial identifica el lenguaje del ecosistema analizador explicado en el artículo. Crédito: pkg.go.dev.
Un analizador se representa mediante un valor `Analyzer` que describe su nombre, documentación, indicadores, dependencias, tipos de hechos y función de ejecución. Un controlador recibe un `Pass` correspondiente a un paquete, proporciona información de sintaxis y de tipos, ejecuta primero los analizadores necesarios y expone sus resultados mediante `Pass.ResultOf`. Después, el analizador informa diagnósticos con posiciones de origen a través del pase. Esta separación permite a los autores de herramientas elegir qué comprobaciones ejecutar sin reescribir cada comprobador para una interfaz concreta.
La idea central de escalabilidad del framework es el `Fact`. Un hecho es un resultado intermedio que no necesariamente resulta útil por sí solo para una persona desarrolladora, pero que puede ayudar a otro análisis a llegar a una conclusión. La documentación ofrece el comprobador `printf` como ejemplo: puede identificar una función como un contenedor de `printf`, exportar ese hecho y permitir que análisis posteriores de paquetes apliquen comprobaciones más estrictas a las llamadas que se delegan a través del contenedor.
Los hechos pueden asociarse con un objeto con nombre o con un paquete completo. Los controladores son responsables de generar hechos para las dependencias y propagarlos a través de los límites entre paquetes, incluso entre procesos separados. Como los hechos pueden almacenarse en resultados de compilación, la API exige una serialización gob determinista; también se aconseja a las personas autoras de analizadores que mantengan los hechos sin estado para que las cachés de compilación basadas en contenido no sufran fallos de acierto innecesarios.
El diseño excluye deliberadamente la gravedad de los diagnósticos del tipo central `Diagnostic`. La documentación indica que las preferencias de gravedad difieren entre usuarios y herramientas, por lo que los controladores deben proporcionar filtrado y priorización en función del analizador que los produce y de su categoría opcional. Esta decisión mantiene la interfaz del analizador relativamente pequeña, pero también significa que la salida de un comprobador no es automáticamente una lista clasificada de defectos.
Existen límites prácticos. Algunas implementaciones de controladores, incluidas las basadas en Bazel y Blaze descritas por la documentación, actualmente no analizan paquetes de la biblioteca estándar de Go. Por ello, el comprobador `printf` incluye un hecho integrado para `log.Printf`, de modo que todavía puede comprobar llamadas cuando no se ha analizado el paquete de la biblioteca estándar. Se trata de una solución alternativa explícita, no de una prueba de que todos los controladores ofrezcan la misma cobertura de paquetes.
La documentación también distingue entre analizadores que inspeccionan árboles de sintaxis con tipos y aquellos que leen código fuente sin procesar o archivos que no son de Go. Ejemplos como `asmdecl` y `buildtag` muestran que el framework puede ir más allá de la información ordinaria de tipos, pero la persona autora del analizador sigue siendo responsable de definir qué examina el comprobador y cómo comunica sus hallazgos. La API proporciona un contrato; no garantiza que todas las propiedades posibles de un programa puedan inferirse de forma sólida.
Para las pruebas, el subpaquete `analysistest` ejecuta un analizador sobre paquetes de fixtures y comprueba los diagnósticos y hechos esperados mediante comentarios `// want`. Para un uso independiente, `singlechecker` y `multichecker` proporcionan puntos de entrada para un analizador o un conjunto de ellos. Estas facilidades hacen que el framework sea utilizable más allá de una única herramienta interna, aunque no eliminan la necesidad de validar los supuestos del analizador y su grafo de dependencias.
La relevancia más amplia reside en la componibilidad. Los equipos pueden añadir un comprobador a un controlador existente incorporando su analizador a una lista, mientras que las personas que construyen herramientas pueden reutilizar analizadores en distintos entornos. La evidencia establece la interfaz documentada, los ejemplos y las responsabilidades declaradas de los controladores; no establece tasas de adopción, referencias de rendimiento ni que todo el ecosistema de herramientas de Go implemente el framework de la misma manera.