scala
Scala 2.13.15
Ceci est le domicile de la bibliothèque standard, du compilateur et des spécifications de langage de Scala 2.
Pour Scala 3, visitez Scala / Scala3.
Les problèmes et les rapports de bogues pour Scala 2 sont situés à Scala / Bug. Ce tracker est également l'endroit où de nouveaux contributeurs peuvent trouver des problèmes sur lesquels travailler: de bons premiers problèmes, aidez-vous.
Pour coordonner des efforts plus larges, nous utilisons également le tracker Scala / Scala-Dev.
Pour contribuer ici, veuillez ouvrir une demande de traction de votre fourche de ce référentiel.
Sachez que nous ne pouvons pas accepter les ajouts à la bibliothèque standard, uniquement des modifications au code existant. La compatibilité binaire interdit l'ajout de nouvelles classes publiques ou de méthodes publiques. Les ajouts sont à la place à Scala-Library-Next.
Nous devons signer la Scala CLA avant de pouvoir fusionner l'un de vos travaux, pour protéger l'avenir de Scala en tant que logiciel open source.
Le flux de travail général est le suivant.
Pour plus d'informations sur la construction et le développement du noyau de Scala, lisez le reste de cette lecture, en particulier pour la configuration de votre machine!
Afin de contacter d'autres contributeurs Scala, rejoignez la chaîne # Scala-Contributeurs sur le chat Scala Discord, ou publiez sur des contributeurs.scala-lang.org (discours).
Si vous avez besoin d'aide avec vos relations publiques à tout moment, n'hésitez pas à @ -metion quelqu'un de la liste ci-dessous, et nous ferons de notre mieux pour vous aider:
| nom d'utilisateur | Parlez-moi de ... | |
|---|---|---|
@lrytz | Back end, optimiseur, arguments nommés et par défaut, journalistes | |
@retronym | 2.12.x branche, performances du compilateur, bugs de compilateur étranges, lambdas | |
@SethTisue | Démarrer, construire, CI, construction communautaire, jenkins, docs, bibliothèque, repose | |
@dwijnand | Match Matcher, Mima, | |
@som-snytt | Avertissements / peluches / erreurs, REPL, Options de compilateur, internes du compilateur, | |
@Ichoran | Bibliothèque de collections, performances | |
@viktorklang | concurrence, avenir | |
@sjrd | interactions avec scala.js | |
@NthPortal | bibliothèque, concurrence, scala.math , LazyList , Using , avertissements | |
@bishabosha | Lecteur savoureux | |
@joroKr21 | Types de kilomètres plus élevés, implicits, variance |
PS: Si vous avez du temps libre pour vous aider ici, nous serions ravis d'ajouter votre nom à cette liste!
Cibler la branche la plus ancienne dans laquelle vous souhaitez que vos modifications se retrouvent. Nous fusions périodiquement des branches de libération plus anciennes (par exemple, 2.12.x) à de nouvelles (par exemple 2.13.x).
Si votre modification est difficile à fusionner, il peut vous être demandé de soumettre également un RP distinct ciblant la succursale plus récente.
Si votre modification est spécifique à la version et ne doit pas être fusionnée, mettez [nomerge] dans le nom de relations publiques.
Si votre changement est un backport d'une succursale plus récente et n'a donc pas besoin d'être fusionné, mettez [backport] dans le nom de PR.
La plupart des modifications devraient cibler 2.13.x. Nous sommes de plus en plus réticents à cibler 2.12.x sauf s'il y a une raison particulière (par exemple, si un bug particulièrement mauvais est trouvé, ou s'il y a un parrainage commercial).
La branche 2.11.x est désormais inactive et aucune autre version 2.11.x n'est prévue (à moins que des circonstances inhabituelles et imprévisibles ne surviennent). Vous ne devez pas cibler 2.11.x sans demander d'abord aux responsables.
Plus important encore:
scala/
+--build.sbt The main sbt build definition
+--project/ The rest of the sbt build
+--src/ All sources
+---/library Scala Standard Library
+---/reflect Scala Reflection
+---/compiler Scala Compiler
+--test/ The Scala test suite
+---/files Partest tests
+---/junit JUnit tests
+---/scalacheck ScalaCheck tests
+--spec/ The Scala language specification
Mais aussi:
scala/
+---/library-aux Scala Auxiliary Library, for bootstrapping and documentation purposes
+---/interactive Scala Interactive Compiler, for clients such as an IDE (aka Presentation Compiler)
+---/intellij IntelliJ project templates
+---/manual Scala's runner scripts "man" (manual) pages
+---/partest Scala's internal parallel testing framework
+---/partest-javaagent Partest's helper java agent
+---/repl Scala REPL core
+---/repl-frontend Scala REPL frontend
+---/scaladoc Scala's documentation tool
+---/scalap Scala's class file decompiler
+---/testkit Scala's unit-testing kit
+--admin/ Scripts for the CI jobs and releasing
+--doc/ Additional licenses and copyrights
+--scripts/ Scripts for the CI jobs and releasing
+--tools/ Scripts useful for local development
+--build/ Build products
+--dist/ Build products
+--target/ Build products
Vous avez besoin des outils suivants:
MacOS et Linux fonctionnent. Les fenêtres peuvent fonctionner si vous utilisez Cygwin. L'aide communautaire pour maintenir la construction en travaillant sur Windows et documenter toute configuration nécessaire est appréciée.
Nous sommes reconnaissants pour les licences OSS suivantes:
Pendant le développement ordinaire, une nouvelle version de Scala est construite par la version publiée précédemment, connue sous le nom de "Compilateur de référence" ou, slangony, sous le nom de "Starr" (version de référence stable). La construction avec Starr est suffisante pour la plupart des types de changements.
Cependant, une construction complète de Scala est amorcée . Bootstrap a deux étapes: d'abord, construire avec Starr; Ensuite, renforcez à nouveau en utilisant le compilateur fraîchement construit, laissant Starr derrière. Cela garantit que chaque version Scala peut se construire.
Si vous modifiez la partie de génération de code du compilateur Scala, vos modifications n'apparaîtront que dans le code bytecode de la bibliothèque et du compilateur après un bootstrap. Notre CI fait une construction bootstrapée.
Bootstrap localement : pour effectuer un bootstrap, exécutez restarrFull dans une session SBT. Cela créera et publiera la distribution Scala dans votre référentiel d'artefact local, puis changera SBT pour utiliser cette version comme nouveau scalaVersion . Vous pouvez ensuite revenir en arrière avec reload . Remarque restarrFull écrira également la version Starr sur buildcharacter.properties afin que vous puissiez y retourner avec restarr sans republier. Cela changera la session SBT pour utiliser les répertoires build-restarr et target-restarr au lieu de build and target , ce qui évite d'essuyer les fichiers de classe et les métadonnées incrémentielles. Intellij continuera à être configuré pour compiler et exécuter des tests à l'aide de la version Starr dans versions.properties .
Pour l'histoire sur la façon dont le schéma actuel est arrivé, voir https://groups.google.com/d/topic/scala-internals/gp5jsm1e0fo/discussion.
Construire avec des avertissements mortels : pour faire des avertissements dans le projet mortel (c'est-à-dire les transformer en erreurs), exécutez set Global / fatalWarnings := true dans SBT (remplacer Global par le nom d'un module - tel que reflect - pour ne faire que les avertissements fatals pour ce module). Pour désactiver à nouveau les avertissements mortels, soit reload SBT, soit exécuter set Global / fatalWarnings := false (encore une fois, remplacez Global par le nom d'un module si vous avez uniquement activé les avertissements fatals pour ce module). CI a toujours des avertissements mortels activés.
Une fois que vous avez commencé une session sbt , vous pouvez exécuter l'une des commandes principales:
compile les compiles de tous les sous-projets (bibliothèque, réflexion, compilateur, scaladoc, etc.)scala / scalac Exécutez le REP / compilateur directement à partir de SBT (acceptez les options / arguments)enableOptimizer recharge la construction avec l'optimiseur Scala activé. Nos sorties sont construites de cette façon. Activez cela lorsque vous travaillez sur les améliorations des performances du compilateur. Lorsque l'optimiseur est activé, la construction sera plus lente et les constructions incrémentielles peuvent être incorrectes.setupPublishCore exécute enableOptimizer et configure un numéro de version basé sur le GIT SHA actuel. Souvent utilisé dans le cadre du bootstrap: sbt setupPublishCore publishLocal && sbt -Dstarr.version=<VERSION> testAlldist/mkBin génère des scripts de coureurs ( scala , scalac , etc.) dans build/quick/bindist/mkPack crée une construction dans le format de distribution Scala dans build/packjunit/test exécute les tests JUnit; junit/testOnly *Foo gère un sous-ensemblescalacheck/test exécute les tests Scalacheck, utilisez testOnly pour exécuter un sous-ensemblepartest des tests les plus partiels (accepte les options, essayez partest --help )publishLocal publie localement une distribution (peut être utilisée comme scalaVersion dans d'autres projets SBT)set baseVersionSuffix := "bin-abcd123-SNAPSHOT" où abcd123 est le hachage GIT de la révision publiée. Vous pouvez également utiliser quelque chose de personnalisé comme "bin-mypatch" . Cela modifie le numéro de version de 2.13.2-SNAPSHOT en quelque chose de plus stable ( 2.13.2-bin-abcd123-SNAPSHOT ).-bin marque la version binaire compatible. L'utiliser dans SBT fera 2.13 la scalaBinaryVersion . Si la version n'est pas compatible binaire, nous vous recommandons d'utiliser -pre , par exemple, 2.14.0-pre-abcd123-SNAPSHOT .set ThisBuild / Compile / packageDoc / publishArtifact := false pour sauter des documents API générant / publiant (accélère le processus). Si une commande se traduit par un message d'erreur comme a module is not authorized to depend on itself , il se peut qu'un plugin Global SBT provoque une dépendance cyclique. Essayez de désactiver les plugins Global SBT (peut-être en les commentant temporairement dans ~/.sbt/1.0/plugins/plugins.sbt ).
Nous vous recommandons de conserver des fichiers de test locaux dans le répertoire sandbox qui est répertorié dans le .gitignore du repo scala.
Notez que la compilation incrémentielle de SBT est souvent trop grossière pour la base de code du compilateur Scala et recompile trop de fichiers, ce qui entraîne des temps de construction longs (vérifiez SBT # 1104 pour les progrès sur ce front). En attendant, vous pouvez:
Nous suggérons d'utiliser Intellij Idea (voir SRC / Intellij / Readme.md).
Les métaux peuvent également fonctionner, mais nous n'avons pas encore d'instructions ni de configuration d'échantillonnage pour cela. Une demande de traction dans ce domaine serait extrêmement bienvenue. En attendant, nous recueillons des conseils sur Scala / Scala-Dev # 668.
Afin d'utiliser le compilateur incrémentiel d'Intellij:
dist/mkBin dans SBT pour obtenir une construction et les scripts des coureurs dans build/quick/bin Vous pouvez maintenant modifier et construire Intellij et utiliser les scripts (compilateur, REPL) pour tester directement vos modifications. Vous pouvez également exécuter les commandes scala , scalac et partest de SBT. Activez le "mode Ant" (expliqué ci-dessus) pour empêcher le compilateur incrémentiel de SBT de recompiller (trop) des fichiers avant chaque invocation partest .
Nos directives pour la contribution sont expliquées dans la contribution.md. Il contient des informations utiles sur nos normes de codage, nos tests, notre documentation, la façon dont nous utilisons Git et Github et comment faire examiner votre code.
Vous pouvez également consulter les ressources suivantes:
Une fois que vous avez soumis un PR, vos commits seront automatiquement testés par le Scala CI.
Notre configuration CI évolue toujours. Voir Scala / Scala-Dev # 751 pour plus de détails sur la façon dont les choses fonctionnent actuellement et comment nous nous attendons à ce qu'ils puissent changer.
Si vous voyez une défaillance parasite sur Jenkins, vous pouvez publier /rebuild en tant que commentaire de relations publiques. Le Scabot Readme répertorie toutes les commandes disponibles.
Si vous souhaitez tester votre patch avant de tout être poli pour examen, vous pouvez faire construire votre branche Travis CI (assurez-vous d'avoir une fourchette et que Travis CI soit activé pour les constructions de branche en premier, puis poussez votre branche). N'hésitez pas à soumettre un projet de PR. Dans le cas où votre succursale contient un grand nombre de commits (que vous n'avez pas encore nettoyé / écrasé pour examen), envisagez d'ajouter [ci: last-only] au titre PR. De cette façon, seul le dernier commit sera testé, économisant une certaine énergie et des ressources CI. Notez que le projet inactif PRS sera finalement fermé, ce qui ne signifie pas que le changement est rejeté.
CI effectue un bootstrap de compilateur. La première tâche, validatePublishCore , publie une construction de votre engagement dans le référentiel temporaire https://scala-ci.typesafe.com/artifactory/scala-p-validation-snapshots. Notez que cette construction n'est pas encore enracée, son bytecode est construit en utilisant le Starr actuel. Le numéro de version est 2.13.2-bin-abcd123-SNAPSHOT où abcd123 est le hachage de validation. Pour les versions binaires incompatibles, le numéro de version est 2.14.0-pre-abcd123-SNAPSHOT .
Vous pouvez utiliser Scala Builds dans le référentiel de validation localement en ajoutant un résolveur et en spécifiant la scalaVersion correspondante:
$ sbt
> set resolvers += "pr" at "https://scala-ci.typesafe.com/artifactory/scala-pr-validation-snapshots/"
> set scalaVersion := "2.12.2-bin-abcd123-SNAPSHOT"
> console
Le Scala CI les publie sur https://scala-ci.typesafe.com/artifactory/scala-integration/.
L'utilisation d'une version nocturne dans SBT et d'autres outils est expliquée sur cette page DOC.
Bien que nous les appelions avec désinvolture comme des constructions "nocturnes", elles ne sont pas réellement construites tous les soirs, mais "funérations". C'est-à-dire qu'une version est publiée pour chaque PR fusionné.
Le Scala CI fonctionne comme une instance Jenkins sur scala-ci.typesafe.com, configuré par un livre de cuisine Chef à Scala / Scala-Jenkins-Infra.
Le bot de construction qui regarde PRS, déclenche des builds de tests et applique l'étiquette "examinée" après qu'un commentaire LGTM est dans le repo Scala / Scabot.
La construction de la communauté Scala est une méthode importante pour tester les versions de Scala. Une construction communautaire peut être lancée pour tout engagement de Scala, même avant que le RP de la commission n'ait été fusionné. Cet engagement est ensuite utilisé pour construire un grand nombre de projets open source de Source et exécuter leurs suites de test.
Pour demander une construction communautaire exécutée sur votre RP, demandez simplement dans un commentaire sur les relations publiques et un membre de l'équipe Scala (probablement @Sethtisue) s'en occupera. (détails)
Les constructions communautaires fonctionnent sur l'instance de Scala Jenkins. Les emplois sont nommés ..-integrate-community-build . Voir le repo Scala / Community-Builds.
