Go 1.17 est disponible et s'accompagne de la prise en charge de l'architecture ARM 64 bits sous Windows

Cette version maintient la promesse de compatibilité avec Go 1

La dernière version de Go, la version 1.17, arrive six mois après Go 1.16. La plupart de ses changements concernent la mise en œuvre de la chaîne d'outils, du runtime et des bibliothèques. Comme toujours, la version maintient la promesse de compatibilité Go 1.

Modifications apportées au langage

Go 1.17 comprend trois améliorations mineures apportées au langage.

• Conversions de slice en pointeur de tableau : Une expression s de type []T peut maintenant être convertie en pointeur de tableau de type *[N]T. Si a est le résultat d'une telle conversion, alors les indices correspondants qui sont dans la plage se réfèrent aux mêmes éléments sous-jacents*: &a[i] == &s[i] pour 0 <= i < N. La conversion panique si len(s) est inférieur à N.
• unsafe.Add : unsafe.Add(ptr, len) ajoute len à ptr et renvoie le pointeur mis à jour unsafe.Pointer(uintptr(ptr) + uintptr(len)).
• unsafe.Slice : pour l'expression ptr de type *T, unsafe.Slice(ptr, len) renvoie un slice de type []T dont le tableau sous-jacent commence à ptr et dont la longueur et la capacité sont len.
  

Ces améliorations ont été ajoutées pour simplifier l'écriture de code conforme aux règles de sécurité de unsafe.Pointer, mais les règles restent inchangées. En particulier, les programmes existants qui utilisent correctement unsafe.Pointer restent valides et les nouveaux programmes doivent toujours suivre les règles lorsqu'ils utilisent unsafe.Add ou unsafe.Slice.

Notez que la nouvelle conversion de pointeur de slice en pointeur de tableau est le premier cas dans lequel une conversion de type peut paniquer au moment de l'exécution. Les outils d'analyse qui supposent que les conversions de type ne peuvent jamais paniquer doivent être mis à jour pour prendre en compte cette possibilité.

Ports

Darwin

Comme annoncé dans les notes de publication de Go 1.16, Go 1.17 nécessite macOS 10.13 High Sierra ou une version ultérieure ; la prise en charge des versions précédentes a été interrompue.

Windows

Go 1.17 ajoute la prise en charge de l'architecture ARM 64 bits sous Windows (le port windows/arm64). Ce port prend en charge cgo.

OpenBSD

L'architecture MIPS 64 bits sur OpenBSD (le port openbsd/mips64) prend désormais en charge cgo.

Dans Go 1.16, sur les architectures ARM 64 bits x86 et 64 bits sur OpenBSD (les ports openbsd/amd64 et openbsd/arm64), les appels système sont effectués via la libc, au lieu d'utiliser directement les instructions machine. Dans Go 1.17, cela est également fait sur les architectures ARM 32 bits x86 et 32 bits sur OpenBSD (les ports openbsd/386 et openbsd/arm). Cela garantit la compatibilité avec les futures versions d'OpenBSD, en particulier avec OpenBSD 6.9 et les versions ultérieures, ce qui nécessite que les appels système soient effectués via la libc pour les binaires Go non statiques.

ARM64

Les programmes Go maintiennent désormais des pointeurs de trame de pile sur l'architecture ARM 64 bits sur tous les systèmes d'exploitation. Auparavant, il ne conservait les pointeurs de trame de pile que sur Linux, macOS et iOS.

Outils

Commandes Go

Graphiques de modules élagués dans les modules Go 1.17

Si un module spécifie go 1.17 ou supérieur, le graphique du module inclut uniquement les dépendances immédiates des autres modules go 1.17, et non leurs dépendances transitives complètes.

Pour que la commande go résolve correctement les importations transitives à l'aide du graphique de module élagué, le fichier go.mod de chaque module doit inclure plus de détails sur les dépendances transitives pertinentes pour ce module. Si un module spécifie go 1.17 ou supérieur dans son fichier go.mod, son fichier go.mod contient désormais une directive require explicite pour chaque module qui fournit un package importé de manière transitive. (Dans les versions précédentes, le fichier go.mod n'incluait généralement que des exigences explicites pour les packages directement importés.)

Étant donné que le fichier go.mod étendu nécessaire pour l'élagage du graphe du module inclut toutes les dépendances nécessaires pour charger les importations de tout package dans le module principal, si le module principal spécifie go 1.17 ou supérieur, l'outil go ne lit plus (ou même ne télécharge) go.mod pour les dépendances si elles ne sont pas nécessaires pour terminer la commande demandée.

Étant donné que le nombre d'exigences explicites peut être considérablement plus important dans un fichier go.mod Go 1.17 étendu, les exigences nouvellement ajoutées sur les dépendances indirectes dans un module go 1.17 sont conservées dans un bloc require distinct du bloc contenant les dépendances directes.

Pour faciliter la mise à niveau vers les graphiques de module élagués Go 1.17, la sous-commande go mod tidy prend désormais en charge un indicateur -go pour définir ou modifier la version go dans le fichier go.mod. Pour convertir le fichier go.mod d'un module existant en Go 1.17 sans modifier les versions sélectionnées de ses dépendances, exécutez*:


Par défaut, go mod tidy vérifie que les versions sélectionnées des dépendances pertinentes pour le module principal sont les mêmes versions qui seraient utilisées par la version précédente de Go (Go 1.16 pour un module qui spécifie go 1.17), et préserve les entrées go.sum requis par cette version, même pour les dépendances qui ne sont normalement pas requises par d'autres commandes.

L'indicateur -compat permet de remplacer cette version pour prendre en charge les versions plus anciennes (ou uniquement les plus récentes), jusqu'à la version spécifiée par la directive go dans le fichier go.mod. Pour ranger un module go 1.17 pour Go 1.17 uniquement, sans enregistrer les sommes de contrôle pour (ou vérifier la cohérence avec) Go 1.16*:


Notez que même si le module principal est rangé avec -compat=1.17, les utilisateurs qui ont besoin du module d'un module go 1.16 ou antérieur pourront toujours l'utiliser, à condition que les packages n'utilisent que des fonctionnalités de langage et de bibliothèque compatibles.

La sous-commande go mod graph prend également en charge l'indicateur -go, ce qui l'amène à signaler le graphique tel qu'il est vu par la version Go indiquée, montrant les dépendances qui pourraient autrement être supprimées.


Commentaires sur l'obsolescence du module

Les auteurs de modules peuvent déprécier un module en ajoutant un // Deprecated: comment à go.mod, puis en marquant une nouvelle version. go get affiche d...