|Number of watchers on Github||9863|
|Number of open issues||109|
|Average time to merge a PR||4 days|
|Open pull requests||479+|
|Closed pull requests||128+|
|Last commit||10 months ago|
|Repo Created||about 7 years ago|
|Repo Last Updated||10 months ago|
|Organization / Author||scala|
|Do you use scala? Leave a review!|
|View open issues (109)|
|View scala activity|
|View on github|
|Fresh, new opensource launches 🚀🚀🚀|
Trendy new open source projects in your inbox! View examples
This is the official repository for the Scala Programming Language.
To contribute to the Scala standard library, Scala compiler, and Scala Language Specification, please send us a pull request from your fork of this repository.
We do have to ask you to sign the Scala CLA before we can merge any of your work into our code base, to protect its open source nature.
For more information on building and developing the core of Scala, make sure to read the rest of this README!
If you need some help with your PR at any time, please feel free to @-mention anyone from the list below, and we will do our best to help you out:
|username||talk to me about...|
||type checker, pattern matcher, infrastructure, language spec|
||build, developer docs, community build, Jenkins, library, the welcome-to-Scala experience|
||compiler performance, weird compiler bugs, Java 8 lambdas, REPL|
||collections library, performance|
||optimizer, named & default arguments|
||specialization, Scaladoc tool|
||quasiquotes, parser, string interpolators, macros in standard library|
||macros and reflection|
||specialization, back end|
||collections, concurrency, specialization|
P.S.: If you have some spare time to help out around here, we would be delighted to add your name to this list!
scala/ +--build.sbt The main sbt build script +--lib/ Pre-compiled libraries for the build +--src/ All sources +---/library Scala Standard Library +---/reflect Scala Reflection +---/compiler Scala Compiler +---/eclipse Eclipse project files +---/intellij IntelliJ project templates +--spec/ The Scala language specification +--scripts/ Scripts for the CI jobs (including building releases) +--test/ The Scala test suite +---/files Partest tests +---/junit JUnit tests +--build/ [Generated] Build output directory
You need the following tools:
Mac OS X and Linux work. Windows may work if you use Cygwin. Community help with keeping the build working on Windows is appreciated.
We are grateful for the following OSS licenses:
During ordinary development, a new Scala build is built by the
previously released version. For short we call the previous release
starr: the stable reference Scala release. Building with starr is
sufficient for most kinds of changes.
However, a full build of Scala (a bootstrap, as performed by our CI) requires two layers. This guarantees that every Scala version can build itself. If you change the code generation part of the Scala compiler, your changes will only show up in the bytecode of the library and compiler after a bootstrap. See below for how to do a bootstrap build locally.
For history on how the current scheme was arrived at, see https://groups.google.com/d/topic/scala-internals/gp5JsM1E0Fo/discussion.
Once you've started an
sbt session you can run one of the core commands:
compilecompiles all sub-projects (library, reflect, compiler, scaladoc, etc)
scalacrun the REPL / compiler directly from sbt (accept options / arguments)
dist/mkBingenerates runner scripts (
scalac, etc) in
dist/mkPackcreates a build in the Scala distribution format in
testruns the JUnit test,
testOnly *immutable.ListTestruns a subset
partestruns partest tests (accepts options, try
publishLocalpublishes a distribution locally (can be used as
scalaVersionin other sbt projects)
set baseVersionSuffix := "-bin-abcd123-SNAPSHOT"where
abcd123is the git hash of the revision being published. You can also use something custom like
"-bin-mypatch". This changes the version number from
2.12.2-SNAPSHOTto something more stable (
-binstring marks the version binary compatible. Using it in sbt will cause the
2.12. If the version is not binary compatible, we recommend using
set publishArtifact in (Compile, packageDoc) in ThisBuild := falseto skip generating / publishing API docs (speeds up the process).
If a command results in an error message like
a module is not authorized to depend on
itself, it may be that a global SBT plugin (such as Ensime) is
resulting in a cyclical dependency. Try disabling global SBT plugins (perhaps by
temporarily commenting them out in
We recommend to keep local test files in the
sandbox directory which is listed in
.gitignore of the Scala repo.
Note that sbt's incremental compilation is often too coarse for the Scala compiler codebase and re-compiles too many files, resulting in long build times (check sbt#1104 for progress on that front). In the meantime you can:
Ant modein which sbt only re-compiles source files that were modified. Create a file
local.sbtcontaining the line
antStyle := true.
To perform a bootstrap using sbt
starr) is used to build / publish the actual build.
publishLocal(you may want to specify a custom version suffix and skip generating API docs, see above).
<version>is the version number you published locally.
set every scalaBinaryVersion := "2.12.0-M4". This is not required if the version you published locally is binary compatible, i.e., if the current
starris a 2.12.x release and not a milestone / RC.
The last step is required to resolve modules (scala-xml, scala-partest, etc). It
assumes that the module releases for the current
starr work (in terms of binary
compatibility) with the local starr that you published locally. A full bootstrap
requires re-building the all the modules. On our CI this is handled by the
bootstrap script, but it (currently) cannot
be easily executed locally.
In order to use IntelliJ's incremental compiler:
dist/mkBinin sbt to get a build and the runner scripts in
Make Projectin IntelliJ
Now you can edit and build in IntelliJ and use the scripts (compiler, REPL) to
directly test your changes. You can also run the
commands in sbt. Enable
Ant mode (explained above) to prevent sbt's incremental
compiler from re-compiling (too many) files before each
Our guidelines for contributing are explained in CONTRIBUTING.md. It contains useful information on our coding standards, testing, documentation, how we use git and GitHub and how to get your code reviewed.
You may also want to check out the following resources:
Scala Hacker Guidecovers some of the same ground as this README, but in greater detail and in a more tutorial style, using a running example.
Once you submit a PR your commits will be automatically tested by the Scala CI.
If you see a spurious build failure, you can post
/rebuild as a PR comment.
The scabot README lists all available commands.
If you'd like to test your patch before having everything polished for review,
feel free to submit a PR and add the
WIP label. In case your WIP branch contains
a large number of commits (that you didn't clean up / squash yet for review),
[ci: last-only] to the PR title. That way only the last commit
will be tested, saving some energy and CI-resources. Note that inactive WIP PRs
will be closed eventually, which does not mean the change is being rejected.
CI performs a full bootstrap. The first task,
a build of your commit to the temporary repository
Note that this build is not yet bootstrapped, its bytecode is built using the
starr. The version number is
is the commit hash. For binary incompatible builds, the version number is
You can use Scala builds in the validation repository locally by adding a resolver
and specifying the corresponding
$ sbt > set resolvers += "pr" at "https://scala-ci.typesafe.com/artifactory/scala-pr-validation-snapshots/" > set scalaVersion := "2.12.2-bin-abcd123-SNAPSHOT" > console
Note that the scala modules are currently not built/published against the tested version during CI validation.
The Scala CI builds nightly download releases (including all modules) and publishes them to the following locations:
The CI also publishes nightly API docs:
Using a nightly build in sbt is explained in this Stack Overflow answer
The build bot that watches PRs, triggers testing builds and applies the
after an LGTM comment is in the scala/scabot repo.
The Scala community build is a central element for testing Scala releases. A community build can be launched for any Scala commit, even before the commit's PR has been merged. That commit is then used to build a large number of open-source projects from source and run their test suites.
To request a community build run on your PR, just ask in a comment on the PR and a Scala team member will take care of it. (details)
Community builds run on the Scala Jenkins instance. The jobs are
..-integrate-community-build. See the
Thanks to Miles Sabin's hard work (sponsored by Lightbend), this milestone adds support for literal types, as well as improving the compiler with better support for typelevel programming, to benefit libraries such as Shapeless. More of this is coming in M4.
The standard library now adheres to the compact1 profile, enabling a signification reduction of the deployment footprint of Scala applications.
Most importantly, this is the last 2.13 milestone with the old collection library! The next (and last) milestone of this series will integrate the new collections incubating at https://github.com/scala/collection-strawman/. For the next few months, our focus will be on integrating, refining, optimizing the new implementation. Our foremost concern is to ensure a smooth upgrade experience, and we are eager to hear your feedback on this as you begin porting your projects. We will document how to try out the new collections as soon as binaries are available, so you don't have to wait until M4 (see M4 milestone for target date and open issues).
A special welcome to @joroKr21 and @japgolly, and a shoutout to the growing team of regulars who keep the PR queue filled with excellence and kindness: @som-snytt, @mkeskells and @hrhino! They authored several of the additional PRs we'd like to highlight for this milestone: https://github.com/scala/scala/pulls?q=is%3Amerged+is%3Apr+milestone%3A2.13.0-M3+label%3Arelease-notes.
-Xsource:2.13 is now enabled by default (we overlooked that in the previous milestones). To facilitate upgrading,
-Xsource:2.12 allows opting out of a few breaking changes. Starting in 2.13, the source version will be the only option that influences language semantics, obsoleting
-Xexperimental and the various
To use Scala 2.13.0-M3, Scala.js users must upgrade to Scala.js 0.6.22, 1.0.0-M3, or newer versions. Prior releases are not compatible.
A big thank you to everyone who's helped improve Scala by reporting bugs, improving our documentation, spreading kindness in discussions around Scala, and submitting and reviewing pull requests! You are all magnificent.
This release was brought to you by 46 contributors, according to
git shortlog -sn --no-merges v2.13.0-M2..v2.13.0-M3. Thank you, Jason Zaugg, Lukas Rytz, Miles Sabin, Adriaan Moors, A. P. Marki, Harrison Houghton, Mike Skells, jvican, Philippus Baalman, Seth Tisue, Eyal Farago, Stefan Zeiger, Tomas Mikula, Martijn Hoekstra, Janek Bogucki, Jasper Moeys, Rex Kerr, Juliusz Sompolski, Ben Elliott, Markus Hauck, id.ilych, Steve Robinson, mkeskells, Georgi Krastev, Kenji Yoshida, Edin Dudojevi, Dhirendra Kumar Kashyap, Nafer Sanabria, Pavel Petlinsky, David Barri, (Yang Bo), Arnout Engelen, Teemu Lehtinen, Allison H, cong, ghik, Aaron S. Hawley, svatsan, Julien Richard-Foy, Kamil Kloch, Marconi Lanna, Edmund Noble, Martin Grotzke, Martynas Mickeviius, Matt Sicker, Mike!
Scala releases are available through a variety of channels, including (but not limited to):
Scala 2.11.12 is a maintenance release to allow running Scala 2.11 tooling on Java 9. Five pending backports were merged.
This release addresses (#6108) a privilege escalation vulnerability that was identified in the Scala compilation daemon CVE-2017-15288.
We strongly encourage you to upgrade to the latest stable version of Scala 2.12.x, as the 2.11.x series is no longer actively maintained.
There is a known bug on Java 9 involving the repl: the workaround is to launch it as
More general information about the Scala 2.11 series is available in the release notes for Scala 2.11.1.
Scala 2.10.7 is a maintenance release to bring (partial) Java 9 support to the sbt 0.13 series. A total of three pending backports were merged.
This release addresses (#6128) a privilege escalation vulnerability that was identified in the Scala compilation daemon CVE-2017-15288.
We strongly encourage you to upgrade to the latest stable version of Scala 2.12.x, as the 2.10.x series is no longer actively maintained.
There is a known bug on Java 9 involving the repl: the workaround is to launch it as