Sortie de la version 1.22 du langage Go, apportant des changements à l'implémentation de la chaîne d'outils

Au moteur d'exécution et aux bibliothèques

La dernière version de Go, la version 1.22, arrive six mois après Go 1.21. La plupart des changements concernent l'implémentation de la chaîne d'outils, du moteur d'exécution et des bibliothèques. Comme toujours, la version maintient la promesse de compatibilité de Go 1. Presque tous les programmes Go devraient continuer à se compiler et à s'exécuter comme auparavant.

Changements apportés au langage

Go 1.22 apporte deux changements aux boucles "for".

• Auparavant, les variables déclarées par une boucle "for" étaient créées une seule fois et mises à jour à chaque itération. Dans Go 1.22, chaque itération de la boucle crée de nouvelles variables, afin d'éviter les bogues de partage accidentel. L'outil d'aide à la transition décrit dans la proposition continue de fonctionner de la même manière que dans Go 1.21.
• Les boucles "For" peuvent désormais porter sur des nombres entiers. Par exemple :
  
  

  Code :

  Sélectionner tout

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  package main
  
  import "fmt"
  
  func main() {
    for i := range 10 {
      fmt.Println(10 - i)
    }
    fmt.Println("go1.22 has lift-off!")
  }

Go 1.22 inclut un aperçu d'un changement de langage envisagé pour une future version de Go : les itérateurs de type "range-over-function". Construire avec GOEXPERIMENT=rangefunc permet d'activer cette fonctionnalité.


Outils

Commande Go

Les commandes dans les workspace peuvent maintenant utiliser un répertoire vendor contenant les dépendances de l'espace de travail. Le répertoire est créé par go work vendor, et utilisé par les commandes build lorsque le drapeau -mod est positionné à vendor, ce qui est le cas par défaut lorsqu'un répertoire vendor de l'espace de travail est présent.

Notez que le contenu du répertoire vendor pour un workspace est différent de celui d'un module unique : si le répertoire à la racine d'un workspace contient également l'un des modules du workspace, son répertoire vendor peut contenir les dépendances soit du workspace, soit du module, mais pas les deux.

go get n'est plus supporté en dehors d'un module dans l'ancien mode GOPATH (c'est-à-dire avec GO111MODULE=off). Les autres commandes de construction, telles que go build et go test, continueront à fonctionner indéfiniment pour les programmes GOPATH hérités.

go mod init ne tente plus d'importer les exigences des modules à partir de fichiers de configuration pour d'autres outils de distribution (tels que Gopkg.lock).

go test -cover imprime maintenant des résumés de couverture pour les paquets couverts qui n'ont pas leurs propres fichiers de test. Avant Go 1.22, une exécution de go test -cover pour un tel paquetage produisait le rapport suivant

? mymod/mypack [no test files]

et maintenant avec Go 1.22, les fonctions du paquet sont traitées comme non couvertes :

mymod/mypack couverture : 0,0 % of statements

Notez que si un paquet ne contient aucun code exécutable, on ne peut pas indiquer un pourcentage de couverture significatif ; pour de tels paquets, l'outil go continuera à indiquer qu'il n'y a pas de fichiers de test.

Trace

L'interface web de l'outil de traçage a été légèrement rafraîchie dans le cadre du travail de support du nouveau traceur, en résolvant plusieurs problèmes et en améliorant la lisibilité de diverses sous-pages. L'interface web permet désormais d'explorer les traces dans une vue orientée thread. Le visualiseur de traces affiche désormais la durée complète de tous les appels système.
Ces améliorations ne s'appliquent qu'à la visualisation des traces produites par des programmes construits avec Go 1.22 ou une version plus récente. Une prochaine version apportera certaines de ces améliorations aux traces produites par des versions plus anciennes de Go.

Vet

• Références aux variables de boucle
  
  Le comportement de l'outil vet a changé pour s'adapter à la nouvelle sémantique (voir ci-dessus) des variables de boucle dans Go 1.22. Lors de l'analyse d'un fichier qui nécessite Go 1.22 ou plus récent (en raison de son fichier go.mod ou d'une contrainte de construction par fichier), vetcode> ne signale plus les références aux variables de boucle à l'intérieur d'un littéral de fonction qui pourrait survivre à l'itération de la boucle. Dans Go 1.22, les variables de boucle sont créées à nouveau pour chaque itération, donc de telles références ne risquent plus d'utiliser une variable après qu'elle ait été mise à jour par la boucle.
• Nouveaux avertissements pour les valeurs manquantes après l'append
  
  L'outil vet signale désormais les appels à append qui ne transmettent aucune valeur à ajouter à la tranche, tels que slice = append(slice). Une telle déclaration n'a aucun effet, et l'expérience a montré que c'est presque toujours une erreur.
• Nouveaux avertissements pour le report de time.Since
  
  L'outil vet signale maintenant un appel non différé à time.Since(t) à l'intérieur d'une déclaration defer. Cela équivaut à appeler time.Now().Sub(t) avant l'instruction de report, et non pas lorsque la fonction reportée est appelée. Dans presque tous les cas, le code correct exige de différer l'appel à time.Since. Par exemple :
  
  

  Code :

  Sélectionner tout

  1
  2
  3
  4
  5
  6
  7
  t := time.Now()
  defer log.Println(time.Since(t)) // non-deferred call to time.Since
  tmp := time.Since(t); defer log.Println(tmp) // equivalent to the previous defer
  
  defer func() {
    log.Println(time.Since(t)) // a correctly deferred call to time.Since
  }()

• Nouveaux avertissements pour les paires clé-valeur non concordantes dans les appels à log/slog
  
  L'outil vet signale désormais les arguments non valides dans les appels aux fonctions et méthodes du paquetage de journalisation structuré, log/slog, qui acceptent des paires clé/valeur alternées. Il signale les appels où un argument dans une position clé n'est ni une chaîne ni un slog.Attr, et où une clé finale n'a pas de valeur.

Temps d'exécution

Le Temps d'exécution (runtime) conserve désormais les métadonnées de garbage collection basées sur les types plus près de chaque objet du tas, ce qui améliore les performances CPU (latence ou débit) des programmes Go de 1 à 3 %. Ce changement réduit également la surcharge mémoire de la majorité des programmes Go d'environ 1 % en dédupliquant les métadonnées redondantes. Certains programmes peuvent voir une amélioration plus faible car ce changement ajuste les limites...