org.scala-lang:scalap
Advanced tools
This is the home of the Scala 2 standard library, compiler, and language spec.
For Scala 3, visit scala/scala3.
Issues and bug reports for Scala 2 are located in scala/bug. That tracker is also where new contributors may find issues to work on: good first issues, help wanted.
For coordinating broader efforts, we also use the scala/scala-dev tracker.
To contribute here, please open a pull request from your fork of this repository.
Be aware that we can't accept additions to the standard library, only modifications to existing code. Binary compatibility forbids adding new public classes or public methods. Additions are made to scala-library-next instead.
We require that you sign the Scala CLA before we can merge any of your work, to protect Scala's future as open source software.
The general workflow is as follows.
For more information on building and developing the core of Scala, read the rest of this README, especially for setting up your machine!
In order to get in touch with other Scala contributors, join the #scala-contributors channel on the Scala Discord chat, or post on contributors.scala-lang.org (Discourse).
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... | |
|---|---|---|
 | @lrytz | back end, optimizer, named & default arguments, reporters |
 | @retronym | 2.12.x branch, compiler performance, weird compiler bugs, lambdas |
 | @SethTisue | getting started, build, CI, community build, Jenkins, docs, library, REPL |
 | @dwijnand | pattern matcher, MiMa, partest |
 | @som-snytt | warnings/lints/errors, REPL, compiler options, compiler internals, partest |
 | @Ichoran | collections library, performance |
 | @viktorklang | concurrency, futures |
 | @sjrd | interactions with Scala.js |
 | @NthPortal | library, concurrency, scala.math, LazyList, Using, warnings |
 | @bishabosha | TASTy reader |
 | @joroKr21 | higher-kinded types, implicits, variance |
P.S.: If you have some spare time to help out around here, we would be delighted to add your name to this list!
Target the oldest branch you would like your changes to end up in. We periodically merge forward from older release branches (e.g., 2.12.x) to new ones (e.g. 2.13.x).
If your change is difficult to merge forward, you may be asked to also submit a separate PR targeting the newer branch.
If your change is version-specific and shouldn't be merged forward, put [nomerge] in the PR name.
If your change is a backport from a newer branch and thus doesn't need to be merged forward, put [backport] in the PR name.
Most changes should target 2.13.x. We are increasingly reluctant to target 2.12.x unless there is a special reason (e.g. if an especially bad bug is found, or if there is commercial sponsorship).
The 2.11.x branch is now inactive and no further 2.11.x releases are planned (unless unusual, unforeseeable circumstances arise). You should not target 2.11.x without asking maintainers first.
Most importantly:
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
but also:
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
You need the following tools:
MacOS and Linux work. Windows may work if you use Cygwin. Community help with keeping the build working on Windows and documenting any needed setup is appreciated.
We are grateful for the following OSS licenses:
During ordinary development, a new Scala build is built by the previously released version, known as the "reference compiler" or, slangily, as "STARR" (stable reference release). Building with STARR is sufficient for most kinds of changes.
However, a full build of Scala is bootstrapped. Bootstrapping has two steps: first, build with STARR; then, build again using the freshly built compiler, leaving STARR behind. 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. Our CI does a bootstrapped build.
Bootstrapping locally: To perform a bootstrap, run restarrFull
within an sbt session. This will build and publish the Scala
distribution to your local artifact repository and then switch sbt to
use that version as its new scalaVersion. You may then revert back
with reload. Note restarrFull will also write the STARR version
to buildcharacter.properties so you can switch back to it with
restarr without republishing. This will switch the sbt session to
use the build-restarr and target-restarr directories instead of
build and target, which avoids wiping out classfiles and
incremental metadata. IntelliJ will continue to be configured to
compile and run tests using the starr version in
versions.properties.
For history on how the current scheme was arrived at, see https://groups.google.com/d/topic/scala-internals/gp5JsM1E0Fo/discussion.
Building with fatal warnings: To make warnings in the project fatal (i.e. turn them into errors), run set Global / fatalWarnings := true in sbt (replace Global with the name of a module—such as reflect—to only make warnings fatal for that module). To disable fatal warnings again, either reload sbt, or run set Global / fatalWarnings := false (again, replace Global with the name of a module if you only enabled fatal warnings for that module). CI always has fatal warnings enabled.
Once you've started an sbt session you can run one of the core commands:
compile compiles all sub-projects (library, reflect, compiler, scaladoc, etc)scala / scalac run the REPL / compiler directly from sbt (accept options /
arguments)enableOptimizer reloads the build with the Scala optimizer enabled. Our releases are built this way. Enable this when working on compiler performance improvements. When the optimizer is enabled the build will be slower and incremental builds can be incorrect.setupPublishCore runs enableOptimizer and configures a version number based on the current Git SHA. Often used as part of bootstrapping: sbt setupPublishCore publishLocal && sbt -Dstarr.version=<VERSION> testAlldist/mkBin generates runner scripts (scala, scalac, etc) in build/quick/bindist/mkPack creates a build in the Scala distribution format in build/packjunit/test runs the JUnit tests; junit/testOnly *Foo runs a subsetscalacheck/test runs scalacheck tests, use testOnly to run a subsetpartest runs partest tests (accepts options, try partest --help)publishLocal publishes a distribution locally (can be used as scalaVersion in
other sbt projects)
set baseVersionSuffix := "bin-abcd123-SNAPSHOT"
where abcd123 is the git hash of the revision being published. You can also
use something custom like "bin-mypatch". This changes the version number from
2.13.2-SNAPSHOT to something more stable (2.13.2-bin-abcd123-SNAPSHOT).-bin string marks the version binary compatible. Using it in
sbt will cause the scalaBinaryVersion to be 2.13. If the version is not
binary compatible, we recommend using -pre, e.g., 2.14.0-pre-abcd123-SNAPSHOT.set ThisBuild / Compile / packageDoc / publishArtifact := false
to 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 is causing
a cyclical dependency. Try disabling global sbt plugins (perhaps by
temporarily commenting them out in ~/.sbt/1.0/plugins/plugins.sbt).
We recommend keeping local test files in the sandbox directory which is listed in
the .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:
We suggest using IntelliJ IDEA (see src/intellij/README.md).
Metals may also work, but we don't yet have instructions or sample configuration for that. A pull request in this area would be exceedingly welcome. In the meantime, we are collecting guidance at scala/scala-dev#668.
In order to use IntelliJ's incremental compiler:
dist/mkBin in sbt to get a build and the runner scripts in build/quick/binNow 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.
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:
Once you submit a PR your commits will be automatically tested by the Scala CI.
Our CI setup is always evolving. See scala/scala-dev#751 for more details on how things currently work and how we expect they might change.
If you see a spurious failure on Jenkins, 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,
you can have Travis CI build your branch (make sure you have a fork and have Travis CI
enabled for branch builds on it first, and then push your branch). Also
feel free to submit a draft PR. In case your draft 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 draft PRs
will be closed eventually, which does not mean the change is being rejected.
CI performs a compiler bootstrap. The first task, validatePublishCore, publishes
a build of your commit to the temporary repository
https://scala-ci.typesafe.com/artifactory/scala-pr-validation-snapshots.
Note that this build is not yet bootstrapped, its bytecode is built using the
current STARR. The version number is 2.13.2-bin-abcd123-SNAPSHOT where abcd123
is the commit hash. For binary incompatible builds, the version number is
2.14.0-pre-abcd123-SNAPSHOT.
You can use Scala builds in the validation repository locally by adding a resolver
and specifying the corresponding scalaVersion:
$ sbt
> set resolvers += "pr" at "https://scala-ci.typesafe.com/artifactory/scala-pr-validation-snapshots/"
> set scalaVersion := "2.12.2-bin-abcd123-SNAPSHOT"
> console
The Scala CI builds nightly download releases and publishes them to https://scala-ci.typesafe.com/artifactory/scala-integration/ .
Using a nightly build in sbt is explained in this Stack Overflow answer
Although we casually refer to these as "nightly" builds, they aren't actually built nightly, but "mergely". That is to say, a build is published for every merged PR.
The Scala CI runs as a Jenkins instance on scala-ci.typesafe.com, 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.
The Scala community build is an important method 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 (probably @SethTisue) will take care of it. (details)
Community builds run on the Scala Jenkins instance. The jobs are
named ..-integrate-community-build. See the
scala/community-builds
repo.
FAQs
bytecode analysis tool
We found that org.scala-lang:scalap demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
A malicious npm package disguised as a WhatsApp client is exploiting authentication flows with a remote kill switch to exfiltrate data and destroy files.
Security News
PyPI now supports digital attestations, enhancing security and trust by allowing package maintainers to verify the authenticity of Python packages.
Security News
GitHub removed 27 malicious pull requests attempting to inject harmful code across multiple open source repositories, in another round of low-effort attacks.