ProHoster > Blog > Actualités Internet > Go 1.24

Go 1.24

Go 1.24

La nouvelle version du langage Go, version 1.24, sort six mois après Go 1.23. La plupart des changements concernent l'implémentation de la chaîne d'outils, du runtime et des bibliothèques. Comme toujours, la version garantit la promesse de compatibilité Go 1. Les développeurs du langage s'attendent à ce que presque tous les programmes Go continuent de se compiler et de fonctionner comme auparavant.

Les changements dans le langage

Go 1.24 prend désormais en charge les alias de type génériques: un alias de type peut être paramétré comme un type déclaré. Plus de détails dans la spécification du langage. Pour l'instant, cette fonctionnalité peut être désactivée en définissant GOEXPERIMENT=noaliastypeparams ; cependant, l'option aliastypeparams sera supprimée dans Go 1.25.

Outils

La commande go

Les modules go peuvent désormais suivre les dépendances exécutables en utilisant la directive tool dans go.mod. Cela élimine le besoin d'une solution de contournement précédente consistant à ajouter des outils en tant qu'importations vides dans le fichier, généralement appelé « tools.go ». La commande go tool peut désormais exécuter ces outils en plus des outils fournis avec Go. Plus d'informations peuvent être trouvées dans documentation.

Le nouveau drapeau -tool pour go get ajoute la directive d'outil au module actuel pour les packages spécifiés, en plus d'ajouter la directive de requirements.

Nouveau Le méta-pattern tool fait référence à tous les outils dans le module actuel. Cela peut être utilisé pour les mettre à jour tous via go get tool ou pour les installer dans votre répertoire GOBIN via go install tool.

Les fichiers exécutables créés via go run et le nouveau comportement de go tool sont désormais mis en cache dans le cache de compilation de Go. Cela rend les exécutions répétées plus efficaces grâce à un cache accru. #69290.

Les commandes go build et go install prennent désormais l'option -json, qui indique les sorties et les erreurs de compilation sous forme de sortie structurée JSON dans la sortie standard. Les détails du format peuvent être trouvés dans go help buildjson.

De plus, go test -json rapporte désormais les sorties et les erreurs de compilation en JSON, en intercalant avec le JSON des résultats des tests. Ils peuvent être distingués par de nouveaux types d'Action, mais s'ils causent des problèmes dans le système d'intégration des tests, il est possible de revenir à la sortie textuelle des compilations via la configuration GODEBUG gotestjsonbuildtext=1.

La nouvelle variable d'environnement GOAUTH offre un moyen flexible d'autoriser le tirage privé des modules. Les détails peuvent être trouvés dans go help goauth.

La commande go build installe désormais la version du module principal dans le binaire compilé, basé sur le tag et/ou le commit du système de contrôle de version. Le suffixe +dirty sera ajouté en cas de modifications non commises. Vous pouvez utiliser le drapeau -buildvcs=false pour omettre les informations de contrôle de version du binaire.

Nouveau configuration GODEBUG toolchaintrace=1 peut maintenant être utilisé pour suivre le processus de sélection de la toolchain dans l'équipe go.

Cgo

Cgo prend en charge les nouvelles annotations pour les fonctions C pour améliorer les performances à l'exécution. #cgo noescape cFunctionName indique au compilateur que la mémoire passée à la fonction C cFunctionName ne s'échappe pas. #cgo nocallback cFunctionName indique au compilateur que la fonction C cFunctionName ne rappelle aucune fonction Go. Plus d'informations peuvent être trouvées dans la documentation cgo.

Cgo refuse actuellement de compiler des appels de fonctions C qui ont plusieurs déclarations incompatibles. Par exemple, si f est déclaré à la fois comme void f(int) et void f(double), cgo renvoie une erreur au lieu de générer une séquence d'appels incorrecte f(0). Nouveau dans cette version est l'amélioration de la détection de cette condition d'erreur lorsque des déclarations incompatibles apparaissent dans différents fichiers. #67699.

Objdump

L'outil objdump prend désormais en charge la désassemblage sur LoongArch 64 bits (GOARCH=loong64), RISC-V (GOARCH=riscv64) et S390X (GOARCH=s390x).

Vet

Le nouvel analyseur tests signale des erreurs courantes dans les déclarations de tests, les fuzzers, les benchmarks et les exemples dans les paquets de tests, telles que des noms mal formés, des signatures incorrectes ou des exemples qui documentent des identifiants inexistants. Certaines de ces erreurs peuvent entraîner l'échec des tests.

L'analyseur printf existant signale désormais des diagnostics pour les appels sous la forme fmt.Printf(s), où s est une chaîne de format non constante, sans d'autres arguments. De tels appels sont presque toujours une erreur, car la valeur de s peut contenir le symbole % ; utilisez plutôt fmt.Print. 60529. Cette vérification tend à faire des découvertes dans le code existant, et est donc appliquée uniquement lorsque la version du langage (comme indiqué par la directive go du fichier go.mod ou les commentaires `//go:build) est au moins Go 1.24, afin d'éviter des échecs de l'intégration continue lors de la mise à jour vers la toolchain Go 1.24.

L'analyseur buildtag existant signale désormais un diagnostic lorsqu'il y a une erreur. limitation de la version de construction supérieure Go dans la directive //go:build. Par exemple, //go:build go1.23.1 fait référence à un release point; au lieu de cela, utilisez //go:build go1.23. #64127.

L'analyseur copylock existant signale désormais un diagnostic lorsque la variable déclarée dans une boucle 'for' triple, telle que for i := iter(); done(i); i = next(i) { ... }, contient un sync.Locker, tel que sync.Mutex. Go 1.22 a changé le comportement de ces boucles pour créer une nouvelle variable à chaque itération, copiant les valeurs de l'itération précédente; cette copie n'est pas sûre pour les verrous. #66387.

GOCACHEPROG

Le binaire interne cmd/go et le mécanisme de mise en cache des tests peuvent désormais être implémentés par des processus enfants, réalisant un protocole JSON entre l'outil cmd/go et le processus enfant, nommé par la variable d'environnement GOCACHEPROG. Auparavant, c'était par GOEXPERIMENT. Les détails du protocole peuvent être consultés dans documentation.

Temps d'exécution

Plusieurs améliorations de performance dans le runtime ont réduit l'overhead CPU de 2 à 3% en moyenne parmi un ensemble de benchmarks représentatifs. Les résultats peuvent varier en fonction de l'application. Ces améliorations incluent une nouvelle implémentation intégrée de la carte basée sur tableaux suédois, une allocation mémoire plus efficace des petits objets et une nouvelle implémentation de mutex dans le runtime.

La nouvelle implémentation intégrée de la carte et le nouveau mutex du runtime peuvent être désactivés respectivement avec les paramètres GOEXPERIMENT=noswissmap et GOEXPERIMENT=nospinbitmutex lors de la construction.

Compilateur

Le compilateur interdisait déjà de définir de nouvelles méthodes avec des types de récepteur générés par cgo, mais il était possible de contourner cette restriction par un alias de type. Go 1.24 signale désormais toujours une erreur si le récepteur désigne un type cgo généré, directement ou indirectement (par un alias de type).

Linker

Le linker génère désormais un identifiant de construction GNU (enregistrement ELF NT_GNU_BUILD_ID) sur les plateformes ELF et un UUID (commande de chargement Mach-O LC_UUID) sur macOS par défaut. L'identifiant de construction ou l'UUID est dérivé de l'identifiant de construction Go. Cela peut être désactivé par le drapeau du linker -B none, ou remplacé par le drapeau du linker -B 0xNNNN avec la valeur hexadécimale spécifiée par l'utilisateur.

Déploiement

Comme indiqué dans les notes de version de Go 1.22, Go 1.24 nécessite maintenant Go 1.22.6 ou une version ultérieure pour être déployé. Les développeurs s'attendent à ce que Go 1.26 nécessite un correctif de Go 1.24 ou une version ultérieure.

Bibliothèque standard

Accès au système de fichiers limité par répertoire

Nouveau type os.Root permet d'effectuer des opérations sur le système de fichiers dans un répertoire donné.

Fonction os.OpenRoot ouvre un répertoire et renvoie os.Root. Les méthodes sur os.Root opèrent dans ce répertoire et ne permettent pas aux chemins de référencer des emplacements en dehors de celui-ci, y compris ceux qui suivent des liens symboliques en dehors du répertoire. Les méthodes sur os.Root reflètent la plupart des opérations du système de fichiers disponibles dans le package os, y compris, par exemple, os.Root.Open, os.Root.Create, os.Root.Mkdir et os.Root.Stat.

Nouvelle fonction de benchmark

Les benchmarks peuvent maintenant utiliser une méthode plus rapide et moins sujette aux erreurs testing.B.Loop pour itérer le benchmark comme for b.Loop() { … } au lieu de la structure cyclique typique impliquant b.N comme for range b.N. Cela offre deux avantages significatifs :

  • La fonction de benchmark s'exécute exactement une fois par -count, donc les étapes d'installation et de nettoyage coûteuses ne s'exécutent qu'une seule fois.
  • Les paramètres de l'appel de fonction et les résultats continuent d'exister, empêchant le compilateur d'optimiser complètement le corps de la boucle.

Finaliseurs améliorés

La nouvelle fonction runtime.AddCleanup est un mécanisme de nettoyage qui est plus flexible, plus efficace et moins sujet aux erreurs que runtime.SetFinalizer. AddCleanup attache une fonction de nettoyage à un objet, qui s'exécutera dès que l'objet deviendra inaccessible. Cependant, contrairement à SetFinalizer, plusieurs nettoyages peuvent être attachés à un même objet, les nettoyages peuvent être attachés à des pointeurs internes, les nettoyages ne provoquent généralement pas de fuites lorsqu'il existe des cycles d'objets, et ils ne retardent pas la libération de l'objet ou des objets auxquels il fait référence. Le nouveau code devrait préférer AddCleanup à SetFinalizer.

Nouveau package weak

Le nouveau package weak fournit des pointeurs faibles.

Les pointeurs faibles sont un primitif de bas niveau, fourni pour créer des structures qui utilisent efficacement la mémoire, comme des dictionnaires faibles pour faire correspondre des valeurs, des dictionnaires de canonisation pour tout ce qui n'est pas couvert par le package unique, et différents types de caches. Pour prendre en charge ces cas d'utilisation, cette version fournit également runtime.AddCleanup et maphash.Comparable.

Nouveau paquet crypto/mlkem

Le nouveau package crypto/mlkem implémente ML-KEM-768 et ML-KEM-1024.

ML-KEM est un mécanisme d'échange de clés post-quantique, anciennement connu sous le nom de Kyber et spécifié dans FIPS 203.

Nouveaux paquets crypto/hkdf, crypto/pbkdf2 et crypto/sha3

Le nouveau package crypto/hkdf implémente une fonction de génération de clés basée sur HMAC « Extract-and-Expand » HKDF, comme défini dans RFC 5869.

Le nouveau package crypto/pbkdf2 implémente une fonction de génération de clés basée sur un mot de passe PBKDF2, comme défini dans RFC 8018.

Le nouveau package crypto/sha3 implémente la fonction de hachage SHA-3 et les fonctions SHAKE et cSHAKE à sortie variable, comme défini dans FIPS 202.

Tous les trois paquets sont basés sur des paquets existants précédemment golang.org/x/crypto/....

Conformité FIPS 140-3

Cette version inclut un nouvel ensemble de mécanismes pour assurer la conformité FIPS 140-3.

Le module cryptographique Go est un ensemble de paquets internes de la bibliothèque standard, utilisés de manière transparente pour implémenter des algorithmes FIPS 140-3 approuvés. Les applications ne nécessitent aucun changement pour utiliser le module cryptographique Go pour les algorithmes approuvés.

La nouvelle variable d'environnement GOFIPS140 peut être utilisée pour choisir la version du module cryptographique Go à utiliser lors de la compilation. Le nouveau configuration GODEBUG fips140 peut être utilisé pour activer le mode FIPS 140-3 à l'exécution.

Go 1.24 inclut le module cryptographique Go version v1.0.0, qui est actuellement testé avec un laboratoire CMVP accrédité.

Nouveau paquet expérimental testing/synctest

Nouveau paquet expérimental testing/synctest fournit un support pour le test de code concurrent.

  • Fonction synctest.Run exécute un groupe de goroutines dans une « bulle » isolée. Dans la bulle, les fonctions du paquet time opèrent sur des horloges factices.
  • Fonctions synctest.Wait attend que toutes les goroutines soient bloquées dans la bulle actuelle.

Les détails peuvent être consultés dans la documentation du paquet.

Le paquet synctest est expérimental et doit être activé en définissant GOEXPERIMENT=synctest. L'API du paquet peut changer dans de futures versions. Dans #67434 vous pouvez voir plus de détails et fournir des commentaires.

Modifications mineures dans la bibliothèque

archive

Les implémentations (*Writer.AddFS) dans archive/zip et archive/tar écrivent maintenant l'en-tête du répertoire pour un répertoire vide.

bytes

Package bytes ajoute plusieurs fonctions qui travaillent avec des itérateurs :

  • Lines renvoie un itérateur sur les lignes séparées par de nouvelles lignes dans un tableau d'octets.
  • SplitSeq renvoie un itérateur sur tous les sous-segments d'un tableau d'octets, séparés par un séparateur.
  • SplitAfterSeq renvoie un itérateur sur les sous-segments d'un tableau d'octets, séparés après chaque occurrence du séparateur.
  • FieldsSeq renvoie un itérateur sur les sous-segments d'un tableau d'octets autour des séquences de caractères d'espace, comme défini. unicode.IsSpace
  • FieldsFuncSeq renvoie un itérateur sur les sous-segments d'un tableau d'octets autour des séquences de points de code Unicode satisfaisant un prédicat.

crypto/aes

Valeur renvoyée NewChipher ne met plus en œuvre les méthodes NewCTR, NewGCM, NewCBCEncrypter et NewCBCDecrypter. Ces méthodes n'étaient pas documentées et n'étaient pas disponibles sur toutes les architectures. Maintenant, la valeur Block doit être passée directement aux fonctions correspondantes. crypto/cipher. Actuellement, crypto/cipher vérifie toujours ces méthodes sur les valeurs Block, même si elles ne sont plus prises en charge par la bibliothèque standard.

crypto/cipher

La nouvelle fonction NewGCMWithRandomNonce retourne AEAD, qui met en œuvre AES-GCM en générant un numéro unique aléatoire lors du Seal et en l'ajoutant au début du texte chiffré.

Mise en œuvre Stream, renvoyé NewCTR lorsqu'il est utilisé avec crypto/aes maintenant plusieurs fois plus rapide sur amd64 et arm64.

NewOFB, NewCFBEncrypter et NewCFBDecrypter sont désormais déclarés obsolètes. Les modes OFB et CFB ne sont pas authentifiés, ce qui permet en général aux attaques actives de manipuler et de restaurer le texte ouvert. Les applications sont invitées à utiliser AEAD à la place. Si un mode non authentifié Stream est nécessaire, il est possible d'utiliser NewCTR à la place.

crypto/ecdsa

PrivateKey.Sign crée maintenant une signature déterministe conforme à RFC 6979, si la source de hasard est nil.

crypto/md5

Valeur renvoyée md5.New, met maintenant également en œuvre l'interface encoding.BinaryAppender.

crypto/rand

Fonction Lire garantit maintenant l'absence d'échec. Si Read rencontre une erreur lors de la lecture Reader, le programme se terminera de manière irréversible. Notez que le Reader par défaut est documenté pour toujours fonctionner avec succès, donc ce changement ne devrait concerner que les programmes qui redéfinissent la variable Reader. Une seule exception concerne les noyaux Linux avant la version 3.17, où le Reader par défaut ouvre encore /dev/urandom et peut échouer.

Sur Linux 6.11 et plus, Reader utilise maintenant l'appel système getrandom via vDSO. C'est plusieurs fois plus rapide, généralement pour de petites lectures.

Sur OpenBSD, Reader utilise maintenant arc4random_buf(3).

La nouvelle fonction Text peut désormais générer des chaînes de texte aléatoires cryptographiquement sécurisées.

crypto/rsa

GenerateKey renvoie maintenant une erreur si une clé de moins de 1024 bits est demandée. Tous les méthodes Sign, Verify, Encrypt, et Decrypt renvoient désormais une erreur si elles sont utilisées avec une clé de moins de 1024 bits. De telles clés ne sont pas sécurisées et ne devraient pas être utilisées. Configuration GODEBUG rsa1024min=0 restaure le comportement précédent, mais les développeurs de Go recommandent de ne le faire que si nécessaire et uniquement dans les tests, par exemple en ajoutant la ligne //go:debug rsa1024min=0 dans le fichier de test. Le nouveau exemple GenerateKey fournit une clé de test standard de 2024 bits facile à utiliser.

Il est maintenant sûr et plus efficace d'appeler PrivateKey.Precompute à PrivateKey.Validate. Precompute est maintenant plus rapide en présence de PrecomputedValues, par exemple lors de l'extraction d'une clé à partir de JSON.

Le paquet rejette désormais plus de clés incorrectes, même lorsque Validate n'est pas appelé, et GenerateKey peut désormais renvoyer de nouvelles erreurs pour des sources aléatoires défectueuses. Les champs Primes et Precomputed de la structure PrivateKey sont désormais utilisés et validés même lorsque certaines valeurs manquent. Des modifications ont également été apportées à crypto/x509 pour l'analyse et l'extraction des clés RSA, décrites ci-dessous.

SignPKCS1v15 et VerifyPKCS1v15 prennent désormais en charge SHA-512/224, SHA-512/256 et SHA-3.

GenerateKey utilise maintenant une méthode légèrement différente pour générer l'exposant privé (la fonction de Carmichael au lieu de la fonction d'Euler). Les applications rares qui reconstruisent uniquement les clés à partir de nombres premiers externes peuvent produire des résultats différents mais compatibles.

Les opérations sur les clés publiques et privées sont désormais jusqu'à deux fois plus rapides sur wasm.

crypto/sha*

crypto/subtle

La nouvelle fonction WithDataIndependentTiming permet à l'utilisateur d'exécuter une fonction avec des fonctionnalités spécifiques à l'architecture, garantissant l'immuabilité de certaines instructions en fonction du temps des valeurs des données. Cela peut être utilisé pour s'assurer que le code conçu pour fonctionner en temps constant n'a pas été optimisé par les fonctions de niveau du processeur de manière à fonctionner en temps variable. Actuellement, WithDataIndependentTiming utilise le bit PSTATE.DIT sur arm64 et ne fait rien sur toutes les autres architectures. Configuration GODEBUG dataindependenttiming=1 active le mode DIT pour tout le programme Go.

Sortie XORBytes doit se superposer complètement ou pas du tout aux entrées. Auparavant, le comportement était indéfini dans le cas contraire, tandis qu'aujourd'hui XORBytes va paniquer.

crypto/tls

Le serveur TLS prend maintenant en charge Encrypted Client Hello (ECH). Cette fonctionnalité peut être activée en remplissant le champ Config.EncryptedClientHelloKeys.

Un nouveau mécanisme d'échange de clés post-quantique X25519MLKEM768 est maintenant pris en charge et activé par défaut lorsque Config.CurvePreferences est nil. Configuration GODEBUG tlsmlkem=0 renvoie par défaut.

Le support de l'échange de clés expérimental X25519Kyber768Draft00 a été supprimé.

L'ordre d'échange de clés est maintenant entièrement géré par le paquet crypto/tls. L'ordre Config.CurvePreferences est maintenant ignoré, et le contenu est uniquement utilisé pour déterminer quels échanges de clés inclure lorsque le champ est rempli.

Un nouveau champ ClientHelloInfo.Extensions énumère la liste des identifiants d'extensions reçus dans le message Client Hello. Cela peut être utile pour le fingerprinting des clients TLS.

crypto/x509

Configuration GODEBUG x509sha1 a été supprimé. Certficicate.Verify ne prend plus en charge les signatures basées sur SHA-1.

OID implémente maintenant les interfaces encoding.BinaryAppender et encoding.TextAppender.

Le champ par défaut des politiques de certificat a été modifié de Certificate.PolicyIdentifiers sur Certificate.Policies. Lors de l'analyse des certificats, les deux champs seront remplis, mais lors de la création de politiques de certificats, ils seront pris du champ Certificate.Policies au lieu de Certificate.PolicyIdentifiers. Ce changement peut être annulé par la configuration GODEBUG x509usepolicies=0.

CreateCertificate va maintenant générer un numéro de série en utilisant une méthode compatible RFC 5280 lors de la transmission du modèle par le champ Certificate.SerialNumber nil, au lieu de provoquer une erreur.

Certificate.Verify prend maintenant en charge la validation des politiques telles que définies dans RFC 5280 et RFC 9618. Le nouveau champ VerifyOptions.CertificatePolicies peut être défini sur un ensemble acceptable de politiques OIDs. Seules les chaînes de certificats avec des graphes de politiques valides seront renvoyées depuis Certificate.Verify.

MarshalPKCS8PrivateKey génère maintenant une erreur au lieu d'extraire une clé RSA incorrecte. (MarshalPKCS1PrivateKey qui ne renvoie pas d'erreur et son comportement avec des clés incorrectes fournies reste indéfini.)

ParsePKCS1PrivateKey et ParsePKCS8PrivateKey valide maintenant et utilise les valeurs CRT encodées, ce qui lui permet de rejeter les clés RSA incorrectes qui étaient acceptées auparavant. Utiliser les réglages GODEBUG x509rsacrt=0 ramène au recalcul des valeurs CRT.

debug/elf

Package debug/elf ajoute la prise en charge du traitement des versions de symboles dans les fichiers ELF (Executable and Linkable Format). La nouvelle méthode File.DynamicVersions renvoie une liste des versions dynamiques définies dans le fichier ELF. La nouvelle méthode File.DynamicVersionNeeds renvoie une liste des versions dynamiques requises par ce fichier ELF, qui sont définies dans d'autres objets ELF. Enfin, les nouveaux champs Symbol.HasVersion et Symbol.VersionIndex indiquent la version du symbole.

encoding

Deux nouvelles interfaces TextAppender et BinaryAppender ont été introduites pour ajouter une représentation textuelle ou binaire de l'objet à un tableau d'octets. Ces interfaces fournissent la même fonctionnalité que TextMarshaler et BinaryMarshaler, mais au lieu d'allouer un nouveau tableau chaque fois, elles ajoutent directement les données au tableau existant. Ces interfaces sont maintenant implémentées par des types de la bibliothèque standard qui implémentent déjà TextMarshaler et/ou BinaryMarshaler.

encoding/json

Lors de l'encodage, un champ de structure avec la nouvelle option omitzero dans le tag de champ de structure sera omis si sa valeur est zéro. Si le type du champ a une méthode IsZero() bool, elle sera utilisée pour déterminer si la valeur est zéro. Sinon, la valeur sera zéro si elle est une valeur nulle pour son type. Le tag de champ omitzero est plus propre et moins sujet aux erreurs que omitempty, lorsque l'intention est d'omettre les valeurs nulles. En particulier, contrairement à omitempty, omitzero omet les valeurs nulles time.Time , ce qui est une source fréquente de problèmes.

Si à la fois omitempty et omitzero sont spécifiés, le champ sera omis si la valeur est vide ou nulle (ou les deux à la fois).

UnmarshalTypeError.Field inclut désormais des structures intégrées pour fournir des messages d'erreur plus détaillés.

go/types

Toutes les structures de données go/types, qui révèlent des séquences de paires de méthodes comme Len() int et At(int) T, disposent désormais également de méthodes qui retournent des itérateurs, permettant de simplifier le code comme celui-ci :

params := fn.Type.(*types.Signature).Params() for i := 0; i < params.Len(); i++ { use(params.At(i)) }

Pour cela :

for param := range fn.Signature().Params().Variables() { use(param) }

Méthodes : Interface.EmbeddedTypes Interface.ExplicitMethods Interface.Methods MethodSet.Methods Named.Methods Scope.Children Struct.Fields Tuple.Variables TypeList.Types TypeParamList.TypeParams Union.Terms

hash/*

log/slog

Nouveau DiscardHandler est un gestionnaire qui n'est jamais activé et qui jette toujours sa sortie.

Niveau et LevelVar implémente désormais l'interface encoding.TextAppender.

math/*

net

ListenCondig utilise désormais MPTCP par défaut sur les systèmes où cela est pris en charge (pour l'instant seulement Linux).

IP implémente désormais l'interface encoding.TextAppender.

net/http

La limitation a changé Transport sur les réponses d'information 1xx reçues en réponse à une demande. Auparavant, cela arrêtait la requête et renvoyait une erreur après avoir reçu plus de 5 réponses 1xx. Désormais, cela renvoie une erreur uniquement si la taille totale de toutes les réponses 1xx dépasse le paramètre de configuration Transport.MaxResponseHeaderBytes.

De plus, lorsqu'une requête a un hook de suivi net/http/httptrace.ClientTrace.Got1xxResponse, il n'y a désormais aucune limite sur le nombre total de réponses 1xx. Le hook Got1xxResponse peut renvoyer une erreur pour arrêter la requête.

Transport et Serveur ont désormais un champ HTTP2, qui permet de configurer les paramètres du protocole HTTP/2.

Les nouveaux champs Server.Protocols et Transport.Protocols offrent un moyen simple de configurer quels protocoles le serveur ou le client HTTP utilisent.

Le serveur et le client peuvent être configurés pour prendre en charge des connexions HTTP/2 non chiffrées.

Lorsque Server.Protocols contient UnencrypterHTTP2, le serveur acceptera les connexions HTTP/2 sur des ports non chiffrés. Le serveur peut accepter à la fois HTTP/1 et HTTP/2 non chiffré sur le même port.

Lorsque Transport.Protocols contient UnencryptedHTTP2 et ne contient pas HTTP1, le transport utilisera HTTP/2 non chiffré pour les adresses http://. Si le transport est configuré pour utiliser à la fois HTTP/1 et HTTP/2 non chiffré, il utilisera HTTP/1.

Le support de HTTP/2 non chiffré utilise « HTTP/2 avec préconnaissance » (RFC 9113, section 3.3). L'en-tête obsolète « Upgrade: h2c » n'est pas pris en charge.

net/netip

Addr, AddrPort et Prefix implémentent maintenant des interfaces encoding.BinaryAppender et encoding.TextAppender.

net/url

URL implémente maintenant également l'interface encoding.BinaryAppender.

os/user

Sous Windows, Current peut maintenant être utilisé sur Windows Nano Server. L'implémentation a été mise à jour pour éviter l'utilisation de fonctions de la bibliothèque NetApi32, qui est absente sur Nano Server.

Sous Windows, Current, Lookup et LookupId prise en charge des comptes de service utilisateur intégrés suivants :

  • NT AUTHORITYSYSTEM
  • NT AUTHORITYLOCAL SERVICE
  • NT AUTHORITYNETWORK SERVICE

Sous Windows, Current a été significativement accélérée lorsque l'utilisateur actuel est connecté à un domaine lent, ce qui est fréquent pour de nombreux utilisateurs d'entreprise. Maintenant, la performance de l'implémentation est de l'ordre de la milliseconde, par rapport à l'ancienne implémentation qui pouvait prendre plusieurs secondes, voire des minutes, pour s'achever.

Sous Windows, Current renvoie désormais l'utilisateur propriétaire du processus lorsque le thread actuel se fait passer pour un autre utilisateur. Auparavant, cela renvoyait une erreur.

regexp

Regexp implémente désormais l'interface encoding.TextAdapter.

runtime

Fonction GOROOT est désormais déclarée obsolète. Dans le nouveau code, il convient de privilégier l'utilisation du chemin système pour identifier le binaire « go », et d'utiliser go env GOROOT pour déterminer GOROOT.

strings

Package strings ajoute plusieurs fonctions pour travailler avec des itérateurs :

  • Lines renvoie un itérateur sur les lignes séparées par de nouvelles lignes dans la chaîne.
  • SplitSeq renvoie un itérateur sur toutes les sous-chaînes de la chaîne, séparées par le séparateur.
  • SplitAfterSeq renvoie un itérateur sur les sous-chaînes de la chaîne, séparées après chaque occurrence du séparateur.
  • FieldsSeq renvoie un itérateur sur les sous-chaînes de la chaîne autour des séquences de caractères d'espace tel que définiunicode.IsSpace
  • FieldsFuncSeq renvoie un itérateur sur les sous-chaînes de la chaîne autour des séquences de points de code unicode qui satisfont le prédicat.

sync

Mise en œuvre sync.Map a été modifiée pour améliorer les performances, en particulier pour les modifications de dictionnaires. Par exemple, la concurrence des modifications de ensembles non chevauchants sur de grands dictionnaires est moins probable, et il n'est plus nécessaire d'accumuler du temps pour atteindre un dictionnaire à faible concurrence.

Si vous rencontrez des problèmes, définissez GOEXPERIMENT=nosynchashtriemap lors de la compilation pour revenir à l'ancienne implémentation et, s'il vous plaît, remplissez le formulaire de problème.

testing

Nouvelles méthodes T.Context et B.Context renvoie le contexte qui est annulé après la fin du test et avant l'exécution des fonctions de nettoyage du test.

Nouvelles méthodes T.Chdir et B.Chdir peuvent être utilisés pour changer le répertoire de travail pendant la durée du test ou du benchmark.

text/template

Les modèles prennent maintenant en charge range-over-func et range-over-int.

time

Temps implémente maintenant les interfaces encoding.BinaryAppender et encoding.TextAppender.

Ports

Linux

Comment c'était déclaré dans les notes de version de Go 1.23, Go 1.24 nécessite un noyau Linux version 3.2 ou ultérieure.

Darwin

Go 1.24 est la dernière version qui fonctionnera sur macOS 11 Big Sur. Go 1.25 nécessitera macOS 12 Monterey ou ultérieure.

WebAssembly

La directive du compilateur go:wasmexport a été ajoutée aux programmes Go pour exporter des fonctions vers l'hôte WebAssembly.

Dans WebAssembly System Interface Preview 1 (GOOS=wasip1 GOARCH=wasm), Go 1.24 prend en charge la compilation d'un programme Go comme reactor/library en spécifiant le flag de construction -buildmode=c-shared.

Plus de types sont désormais autorisés comme type d'argument ou de résultat pour les fonctions go:wasmimport. En particulier, bool, string, uintptr et des pointeurs vers des types spécifiques sont autorisés (les détails peuvent être consultés dans documentation), avec des types d'entiers de 32 bits et 64 bits et des nombres flottants, ainsi que unsafe.Pointer, qui sont déjà autorisés. Ces types sont également autorisés comme types d'argument ou de résultat pour les fonctions go:wasmexport.

Les fichiers de support pour WebAssembly ont été déplacés dans lib/wasm depuis misc/wasm.

La taille de la mémoire d'origine a été considérablement réduite, en particulier pour les petites applications WebAssembly.

Windows

Le port windows/arm 32 bits (GOOS=windows GOARCH=arm) a été marqué comme cassé. Les détails dans #70705

Source : linux.org.ru

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster