scala
Scala 2.13.15
Dies ist die Heimat der Scala 2 Standard Library, Compiler und der Sprachspezifikation.
Für Scala 3 besuchen Sie Scala/Scala3.
Probleme und Fehlerberichte für Scala 2 befinden sich in Scala/Fehler. In diesem Tracker können neue Mitwirkende Probleme finden, an denen sie arbeiten können: Gute erste Themen, Help Wanted.
Für die Koordinierung breiterer Bemühungen verwenden wir auch den Scala/Scala-dev Tracker.
Um hier beizutragen, öffnen Sie bitte eine Pull -Anfrage aus Ihrer Gabel dieses Repositorys.
Beachten Sie, dass wir Ergänzungen zur Standardbibliothek nicht akzeptieren können, sondern nur Änderungen an vorhandenen Code. Binäre Kompatibilität verbietet es, neue öffentliche Klassen oder öffentliche Methoden hinzuzufügen. Ergänzungen werden stattdessen zum Scala-Bibliothek-Next erzielt.
Wir verlangen, dass Sie den Scala CLA unterschreiben, bevor wir Ihre Arbeiten zusammenführen können, um die Zukunft von Scala als Open -Source -Software zu schützen.
Der allgemeine Workflow ist wie folgt.
Weitere Informationen zum Aufbau und zur Entwicklung des Kerns von Scala finden Sie im Rest dieses Readme, insbesondere zum Einrichten Ihrer Maschine!
Um mit anderen Scala-Mitwirkenden in Kontakt zu treten, schließen Sie sich dem #Scala-Contributors-Kanal im Scala Discord-Chat an oder veröffentlichen Sie zu Mitwirkenden.scala-Lang.org (Diskurs).
Wenn Sie zu jeder Zeit Hilfe bei Ihrer PR benötigen, können Sie jemand aus der folgenden Liste @-mention aus der Liste geben, und wir werden unser Bestes tun, um Ihnen zu helfen:
| Benutzername | Sprich mit mir über ... | |
|---|---|---|
@lrytz | Back End, Optimierer, benannte & Standardargumente, Reporter | |
@retronym | 2.12.x Branch, Compiler -Leistung, seltsame Compiler -Fehler, Lambdas | |
@SethTisue | Erste Schritte, Build, CI, Community Build, Jenkins, Docs, Library, Reply | |
@dwijnand | Muster -Matcher, Mima, Partest | |
@som-snytt | Warnungen/Lines/Fehler, Repl, Compiler -Optionen, Compiler -Interna, Partest | |
@Ichoran | Sammlungsbibliothek, Leistung | |
@viktorklang | Parallelität, Zukunft | |
@sjrd | Interaktionen mit scala.js | |
@NthPortal | Bibliothek, Parallelität, scala.math , LazyList , Using , Warnungen | |
@bishabosha | Leckerer Leser | |
@joroKr21 | Typen mit höheren Kern, Implikationen, Varianz |
PS: Wenn Sie hier etwas Zeit haben, um hier zu helfen, freuen wir uns, Ihren Namen dieser Liste hinzuzufügen!
Zielen Sie auf den ältesten Zweig, den Sie ändern möchten.
Wenn es schwierig ist, Ihre Änderung voranzutreiben, werden Sie möglicherweise auch gebeten, auch eine separate PR zu reichen, die auf die neuere Filiale abzielt.
Wenn Ihre Änderung versionspezifisch ist und nicht vorwärts zusammengeführt werden sollte, setzen Sie den PR-Namen [nomerge] .
Wenn Ihre Änderung ein Backport von einem neueren Zweig ist und daher nicht vorwärts verschmolzen werden muss, stellen Sie [backport] in den PR -Namen ein.
Die meisten Änderungen sollten auf 2.13.x abzielen. Wir zögern zunehmend Zielen auf 2.12.x, es sei denn, es gibt einen besonderen Grund (z. B. wenn ein besonders schlechter Fehler gefunden wird oder wenn es kommerzielle Sponsoring gibt).
Die Branche 2.11.x ist jetzt inaktiv und es sind keine weiteren Veröffentlichungen von 2.11.x geplant (es sei denn, ungewöhnliche, unvorhersehbare Umstände entstehen). Sie sollten nicht auf 2.11.x abzielen, ohne zuerst die Betreuer zu fragen.
Am wichtigsten:
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
aber auch:
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
Sie benötigen die folgenden Tools:
MacOS und Linux arbeiten. Windows kann funktionieren, wenn Sie Cygwin verwenden. Die Community -Hilfe bei der Arbeit des Builds unter Windows und Dokumentation aller erforderlichen Setups wird geschätzt.
Wir sind dankbar für die folgenden OSS -Lizenzen:
Während der gewöhnlichen Entwicklung wird ein neuer Scala -Build von der zuvor veröffentlichten Version erstellt, die als "Referenz Compiler" oder, umfangreich als "Starr" (stabile Referenzveröffentlichung), bekannt ist. Der Bau mit Starr reicht für die meisten Arten von Veränderungen aus.
Ein vollständiger Aufbau von Scala ist jedoch starken . Bootstrapping hat zwei Schritte: Erstens bauen Sie mit Starr auf; Bauen Sie dann mit dem frisch gebauten Compiler erneut und lassen Sie Starr zurück. Dies garantiert, dass sich jede Scala -Version selbst aufbauen kann.
Wenn Sie den Codegenerierungsteil des Scala -Compilers ändern, werden Ihre Änderungen nach einer Bootstrap nur im Bytecode der Bibliothek und des Compilers angezeigt. Unser CI macht einen Bootstrain -Build.
Lokaler Bootstrapping : Um eine Bootstrap durchzuführen, führen Sie restarrFull innerhalb einer SBT -Sitzung aus. Dadurch wird die Scala -Verteilung in Ihr lokales Artefakt -Repository aufgebaut und veröffentlichen und dann die SBT so wechseln, diese Version als neue scalaVersion zu verwenden. Sie können dann mit reload zurückkehren. HINWEIS restarrFull wird auch die Starr -Version auf buildcharacter.properties schreiben, damit Sie mit restarr ohne Neuverschiebung wieder darauf wechseln können. Dadurch wird die SBT-Sitzung um die Verwendung der Verzeichnisse build-restarr und target-restarr anstelle von build und target wechselt, wodurch das Auslösen von Klassenklassen und inkrementelle Metadaten vermieden wird. Intellij wird weiterhin so konfiguriert, dass sie Tests mit der STARR -Version in versions.properties kompilieren und ausführen.
Für die Geschichte darüber, wie das aktuelle Schema angekommen war, finden Sie unter https://groups.google.com/d/topic/scala-internals/gp5jsm1e0fo/discussion.
Aufbau mit tödlichen Warnungen : Warnungen im Projekt tödlich machen (dh sie in Fehler verwandeln), leiten Sie set Global / fatalWarnings := true in SBT (ersetzen Sie Global durch den Namen eines Moduls - wie reflect das Modul). Um tödliche Warnungen erneut zu deaktivieren, entweder SBT reload oder leiten Sie set Global / fatalWarnings := false (erneut ersetzen Sie Global durch den Namen eines Moduls, wenn Sie nur tödliche Warnungen für dieses Modul aktiviert haben). CI hat immer tödliche Warnungen ermöglicht.
Sobald Sie eine sbt -Sitzung begonnen haben, können Sie einen der Kernbefehle ausführen:
compile alle Unterprojekte zusammen (Bibliothek, reflektieren, Compiler, Scaladoc usw.)scala / scalac führen den Repl / Compiler direkt von SBT aus (Akzeptieren von Optionen / Argumenten)enableOptimizer den Build mit aktiviertem Scala -Optimierer neu. Unsere Veröffentlichungen werden auf diese Weise gebaut. Aktivieren Sie dies, wenn Sie an Verbesserungen der Compiler -Leistungsverbesserungen arbeiten. Wenn der Optimierer aktiviert ist, ist der Build langsamer und inkrementelle Builds können falsch sein.setupPublishCore läuft enableOptimizer und konfiguriert eine Versionsnummer basierend auf dem aktuellen Git SHA. Häufig als Teil von Bootstrapping verwendet: sbt setupPublishCore publishLocal && sbt -Dstarr.version=<VERSION> testAlldist/mkBin generiert Runner -Skripte ( scala , scalac usw.) in build/quick/bindist/mkPack erstellt einen Build im Scala -Verteilungsformat in build/packjunit/test führt die Junit -Tests aus; junit/testOnly *Foo führt eine Untergruppe ausscalacheck/test führt Skalacheck -Tests aus und verwenden Sie testOnly , um eine Untergruppe auszuführenpartest führt Partestests aus (akzeptiert Optionen, versuchen Sie es partest --help ).publishLocal veröffentlicht lokal eine Verteilung (kann als scalaVersion in anderen SBT -Projekten verwendet werden)set baseVersionSuffix := "bin-abcd123-SNAPSHOT" wobei abcd123 der Git-Hash der veröffentlichten Revision ist. Sie können auch etwas Customs wie "bin-mypatch" verwenden. Dies ändert die Versionsnummer von 2.13.2-SNAPSHOT in etwas Stabileres ( 2.13.2-bin-abcd123-SNAPSHOT ).-bin -Zeichenfolge die Version binär kompatibel markiert. Wenn Sie es in SBT verwenden, wird die scalaBinaryVersion 2.13 beträgt. Wenn die Version nicht binär kompatibel ist, empfehlen wir, -pre , z. B. 2.14.0-pre-abcd123-SNAPSHOT zu verwenden.set ThisBuild / Compile / packageDoc / publishArtifact := false um API -Dokumente zu überspringen / zu veröffentlichen (beschleunigt den Vorgang). Wenn ein Befehl zu einer Fehlermeldung wie a module is not authorized to depend on itself , kann es sein, dass ein globales SBT -Plugin eine zyklische Abhängigkeit verursacht. Versuchen Sie, globale SBT -Plugins zu deaktivieren (möglicherweise indem Sie sie vorübergehend in ~/.sbt/1.0/plugins/plugins.sbt abgeben).
Wir empfehlen, lokale Testdateien im sandbox -Verzeichnis aufzubewahren, das im .gitignore des Scala Repo aufgeführt ist.
Beachten Sie, dass die inkrementelle Zusammenstellung von SBT für die Scala-Compiler-Codebasis häufig zu grob ist und zu viele Dateien neu zusammenfasst, was zu langen Build-Zeiten führt (die SBT#1104 für Fortschritte an dieser Front prüfen). In der Zwischenzeit können Sie:
Wir schlagen vor, die Intellij -Idee zu verwenden (siehe SRC/Intellij/Readme.md).
Metalle können auch funktionieren, aber wir haben noch keine Anweisungen oder eine Beispielkonfiguration dafür. Eine Pull -Anfrage in diesem Bereich wäre äußerst willkommen. In der Zwischenzeit sammeln wir Leitlinien bei Scala/Scala-Dev#668.
Um Intellijs inkrementellem Compiler zu verwenden:
dist/mkBin in SBT aus, um einen Build und die Läufer -Skripte in build/quick/bin zu erhalten Jetzt können Sie intellij bearbeiten und aufbauen und die Skripte (Compiler, Repl) verwenden, um Ihre Änderungen direkt zu testen. Sie können auch die scala , scalac und partest in SBT ausführen. Aktivieren Sie den "Ant-Modus" (oben erläutert), um zu verhindern, dass der inkrementelle Compiler von SBT vor jedem partest -Aufruf (zu viele) Dateien erneut kompiliert.
Unsere Richtlinien für den Beitrag werden im beitragen.md erläutert. Es enthält nützliche Informationen zu unseren Codierungsstandards, Testen, Dokumentation, der Verwendung von Git und GitHub und der Überprüfung Ihres Codes.
Möglicherweise möchten Sie auch die folgenden Ressourcen überprüfen:
Sobald Sie einen PR einreichen, werden Ihre Commits automatisch vom Scala CI getestet.
Unser CI -Setup entwickelt sich immer weiter. In Scala/Scala-Dev#751 finden Sie weitere Informationen darüber, wie die Dinge derzeit funktionieren und wie wir erwarten, dass sie sich ändern könnten.
Wenn Sie einen falschen Versagen bei Jenkins sehen, können Sie als PR -Kommentar /rebuild . Der Scabot Readme listet alle verfügbaren Befehle auf.
Wenn Sie Ihren Patch testen möchten, bevor Sie alles zur Überprüfung poliert haben, können Sie Travis CI Ihre Filiale erstellen lassen (stellen Sie sicher, dass Sie eine Gabel haben und Travis CI für Zweigbusten zuerst aktivieren lassen und dann Ihren Zweig schieben). Fühlen Sie sich auch frei, einen Entwurf der PR einzureichen. Falls Ihr Entwurf für die Niederlassung eine große Anzahl von Commits enthält (die Sie noch nicht zur Überprüfung aufräumten / säuberten), sollten Sie den PR-Titel [ci: last-only] hinzufügen. Auf diese Weise wird nur das letzte Commit getestet, wodurch Energie und CI-Ressourcen gespart werden. Beachten Sie, dass inaktive Entwürfe letztendlich geschlossen werden, was nicht bedeutet, dass die Änderung abgelehnt wird.
CI führt einen Compiler -Bootstrap durch. Die erste Aufgabe, validatePublishCore , veröffentlicht einen Aufbau Ihres Verpflichtung zum temporären Repository https://scala-ci.typesafe.com/artifactory/scala-pr-validation-napshots. Beachten Sie, dass dieser Build noch nicht Bootstrade ist, der Bytecode wird mit dem aktuellen Starr erstellt. Die Versionsnummer ist 2.13.2-bin-abcd123-SNAPSHOT wobei abcd123 der Commit Hash ist. Bei binären inkompatiblen Builds beträgt die Versionsnummer 2.14.0-pre-abcd123-SNAPSHOT .
Sie können Scala -Builds im Validierungsrepository lokal verwenden, indem Sie einen Resolver hinzufügen und die entsprechende scalaVersion angeben:
$ sbt
> set resolvers += "pr" at "https://scala-ci.typesafe.com/artifactory/scala-pr-validation-snapshots/"
> set scalaVersion := "2.12.2-bin-abcd123-SNAPSHOT"
> console
Der Scala CI veröffentlicht diese an https://scala-ci.typesafe.com/artifactory/scala-integration/.
Auf dieser DOC -Seite wird die Verwendung eines nächtlichen Builds in SBT und anderen Tools erläutert.
Obwohl wir diese beiläufig als "nächtliche" Builds bezeichnen, werden sie nicht nächtlich, sondern "fusionell" nicht gebaut. Das heißt, ein Build wird für jede zusammengeführte PR veröffentlicht.
Der Scala CI läuft als Jenkins-Instanz auf Scala-ci.typesafe.com, das von einem Chefkochbuch bei Scala/Scala-Jenkins-Infra konfiguriert ist.
Der Build -Bot, der PRS beobachtet, Tests auslöst und das Label "überprüft" anwendet, nachdem sich ein LGTM -Kommentar im Scala/Scabot -Repo befindet.
Die Scala Community Build ist eine wichtige Methode zum Testen von Scala -Releases. Ein Community -Build kann für jeden Scala -Commit gestartet werden, noch bevor die PR des Commits zusammengeführt wurde. Dieser Commit wird dann verwendet, um eine große Anzahl von Open-Source-Projekten aus der Quelle zu erstellen und ihre Testsuiten durchzuführen.
Um einen Community -Build -Lauf auf Ihrem PR zu beantragen, fragen Sie einfach in einem Kommentar zur PR, und ein Skala -Teammitglied (wahrscheinlich @Sethtisue) wird sich darum kümmern. (Details)
Community -Builds -Aufbaus für den Scala Jenkins -Instanz. Die Jobs werden ..-integrate-community-build . Siehe das Scala/Community-Builds Repo.
