Scala Java CSS JavaScript Shell HTML
Latest commit 5f1a638 Feb 24, 2017 @adriaanm adriaanm committed on GitHub Merge pull request #5732 from retronym/topic/build-info-malarkey
More predictable performance of SBT build startup, reload
Failed to load latest commit information.
doc Revert "Temporarily insource Scalacheck 1.11.6" Nov 1, 2016
lib/ant Remove further references to forkjoin Jul 16, 2015
project Merge pull request #5732 from retronym/topic/build-info-malarkey Feb 24, 2017
scripts during bootstrap, don't build scala-parser-combinators or -swing Feb 14, 2017
spec GH-644: Remove static html styling of spec code blocks Feb 23, 2017
src Merge pull request #5723 from dragos/issue/regression-assert-ide Feb 24, 2017
test increase timeouts on some sys.process tests Feb 23, 2017
tools run partest from sbt always, command line never Feb 9, 2017
.gitattributes SI-9472 make Git use LF line endings on Windows Sep 25, 2015
.gitignore Fix how "sbt" is written Dec 21, 2016
.mailmap update mailmap Jan 28, 2014
.travis.yml Update keypair used to rsync spec to chara Sep 30, 2016 doc: fix README link Nov 1, 2016
Gemfile Update spec build to Jekyll 3.3 Dec 11, 2016
LICENSE Duplicate license in /LICENSE for GitHub Oct 19, 2016 Fix how "sbt" is written Dec 21, 2016
bincompat-backward.whitelist.conf SI-10026 Fix endless cycle in runtime reflection Feb 19, 2017
bincompat-forward.whitelist.conf SD-256 enable colored output by default on unix Feb 21, 2017
build.sbt Workaround bug in Scala runtime reflection on JDK 9 Feb 16, 2017
dbuild-meta.json SI-9560 Remove dependency on parser-combinators/json Jul 22, 2016
gitconfig.SAMPLE New .gitattributes file. Sep 20, 2012 Bump scala-asm version Feb 16, 2017


This is the official repository for the Scala Programming Language.

How to contribute

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!

In order to get in touch with Scala contributors, join the scala/contributors gitter channel or post on the scala-internals mailing list.

Reporting issues

We're still using Jira for issue reporting, so please report any issues over there. (We would love to start using GitHub Issues, but we're too resource-constrained to take on this migration right now.)

Get in touch!

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...
@adriaanm type checker, pattern matcher, infrastructure, language spec
@SethTisue build, developer docs, community build, Jenkins, library, the welcome-to-Scala experience
@retronym compiler performance, weird compiler bugs, Java 8 lambdas, REPL
@Ichoran collections library, performance
@lrytz optimizer, named & default arguments
@VladUreche specialization, Scaladoc tool
@densh quasiquotes, parser, string interpolators, macros in standard library
@xeno-by macros and reflection
@heathermiller documentation
@dickwall process & community, documentation
@dragos specialization, back end
@axel22 collections, concurrency, specialization
@janekdb documentation

P.S.: If you have some spare time to help out around here, we would be delighted to add your name to this list!

Repository structure

+--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

Get Ready to Contribute


You need the following tools:

  • Java SDK. The baseline version is 8 for 2.12.x. It may be possible to use a later SDK for local development, but the CI will verify against the baseline version.
  • sbt. We recommend the sbt-extras runner script. It provides sensible default jvm options (stack and heap size).

Mac OS X and Linux work. Windows may work if you use Cygwin. Community help with keeping the build working on Windows is appreciated.

Build Setup


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

Using the sbt Build

Core commands:

  • compile compiles all sub-projects (library, reflect, compiler, scaladoc, etc)
  • scala / scalac run the REPL / compiler directly from sbt (accept options / arguments)
  • dist/mkBin generates runner scripts (scala, scalac, etc) in build/quick/bin
  • dist/mkPack creates a build in the Scala distribution format in build/pack
  • test runs the JUnit test, testOnly *immutable.ListTest runs a subset
  • partest runs partest tests (accepts options, try partest --help)
  • publishLocal publishes a distribution locally (can be used as scalaVersion in other sbt projects)
    • Optionally set baseVersionSuffix := "abcd123-SNAPSHOT" where abcd123 is the git hash of the revision being published. You can also use something custom like "mypatch". This changes the version number from 2.12.0-SNAPSHOT to something more stable (2.12.0-abcd123-SNAPSHOT).
    • Optionally set publishArtifact in (Compile, packageDoc) in ThisBuild := false to skip generating / publishing API docs (speeds up the process).


We recommend to keep local test files in the sandbox directory which is listed in the .gitignore of the Scala repo.

Incremental Compilation

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:

  • Enable "Ant mode" in which sbt only re-compiles source files that were modified. Create a file local.sbt containing the line antStyle := true. Add an entry local.sbt to your ~/.gitignore.
  • Use IntelliJ IDEA for incremental compiles (see IDE Setup below) - its incremental compiler is a bit less conservative, but usually correct.

Bootstrapping Locally

To perform a bootstrap using sbt

  • first a build is published either locally or on a temporary repository,
  • then a separate invocation of sbt (using the previously built version as starr) is used to build / publish the actual build.

Assume the current starr version is 2.12.0 (defined in and the current version is 2.12.0-SNAPSHOT (defined in build.sbt). To perform a local bootstrap:

  • Run publishLocal (you may want to specify a custom version suffix and skip generating API docs, see above).
  • Quit sbt and start a new sbt instance using sbt -Dstarr.version=<version> where <version> is the version number you published locally.
  • If the version number you published is not binary compatible with the current starr, 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 starr is 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.

IDE Setup

You may use IntelliJ IDEA (see src/intellij/, the Scala IDE for Eclipse (see src/eclipse/, or ENSIME (see this page on the ENSIME site).

In order to use IntelliJ's incremental compiler:

  • run dist/mkBin in sbt to get a build and the runner scripts in build/quick/bin
  • run "Build" - "Make Project" in 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 scala, scalac and partest commands in sbt. Enable "Ant mode" (explained above) to prevent sbt's incremental compiler from re-compiling (too many) files before each partest invocation.

Coding Guidelines

Our guidelines for contributing are explained in 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 CI

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), consider adding [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, validate-publish-core, publishes a build of your commit to the temporary repository Note that this build is not yet bootstrapped, its bytecode is built using the current starr. The version number is 2.12.0-abcd123-SNAPSHOT where abcd123 is the commit hash.

You can use Scala builds in the validation repository locally by adding a resolver and specifying the corresponding scalaVersion:

$ sbt
> set resolvers += "pr" at ""
> set scalaVersion := "2.12.0-abcd123-SNAPSHOT"
> console

Note that the scala modules are currently not built / published against the tested version during CI validation.

Nightly Builds

The Scala CI builds nightly download releases (including all modules) and publishes them to the following locations:

The CI also publishes nightly API docs:

Note that we currently don't publish nightly (or SNAPSHOT) builds in maven or ivy format to any repository. You can track progress on this front at scala-jenkins-infra#133 and scala-dev#68.

Scala CI Internals

The Scala CI runs as a Jenkins instance on, configured by a chef cookbook at scala/scala-jenkins-infra.

The build bot that watches PRs, triggers testing builds and applies the "reviewed" label after an LGTM comment is in the scala/scabot repo.

Community Build

The community build is a central element for testing Scala releases. A community build can be launched for any Scala revision / commit. It first builds the Scala library and compiler and then uses that Scala version to build a large number of open-source projects from source.

Community builds run on the Scala Jenkins instance, the jobs are named ..-integrate-community-build. The community build definitions specifying which projects are built are in the scala/community-builds repo.