Coder Social home page Coder Social logo

scala-partest's Introduction

This is Scala 2! Welcome!

This is the home of the Scala 2 standard library, compiler, and language spec.

For Scala 3, visit scala/scala3.

How to contribute

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.

  1. Find/file an issue in scala/bug (or submit a well-documented PR right away!).
  2. Fork the scala/scala repo.
  3. Push your changes to a branch in your forked repo. For coding guidelines, go here.
  4. Submit a pull request to scala/scala from your forked repo.

For more information on building and developing the core of Scala, read the rest of this README, especially for setting up your machine!

Get in touch!

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!

Branches

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.

Choosing a branch

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.

Repository structure

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

Get ready to contribute

Requirements

You need the following tools:

  • Java SDK. The baseline version is 8 for both 2.12.x and 2.13.x. It is almost always fine to use a later SDK such as 11 or 15 for local development. CI will verify against the baseline version.
  • sbt

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.

Tools we use

We are grateful for the following OSS licenses:

Build setup

Basics

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.

Using the sbt build

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> testAll
  • 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
  • junit/test runs the JUnit tests; junit/testOnly *Foo runs a subset
  • scalacheck/test runs scalacheck tests, use testOnly to run 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 := "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).
    • Note that the -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.
    • Optionally 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).

Sandbox

We recommend keeping 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:

  • Use IntelliJ IDEA for incremental compiles (see IDE Setup below) - its incremental compiler is a bit less conservative, but usually correct.

IDE setup

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:

  • 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 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 CI

Build Status

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

"Nightly" builds

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.

Scala CI internals

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.

Community build

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.

scala-partest's People

Contributors

adriaanm avatar dotta avatar dragos avatar dwijnand avatar gkossakowski avatar gourlaysama avatar gzm0 avatar heathermiller avatar jsuereth avatar khernyo avatar kzys avatar lrytz avatar martijnhoekstra avatar namin avatar odersky avatar paulp avatar phaller avatar prayagverma avatar retronym avatar rkuhn avatar sethtisue avatar smarter avatar soc avatar som-snytt avatar szeiger avatar tiarkrompf avatar vigdorchik avatar vladureche avatar xeno-by avatar xuwei-k avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

scala-partest's Issues

Consolidate Scala.js fork

Partest mark test that timed out as skipped instead of failed

See https://scala-ci.typesafe.com/job/dotty-master-validate-partest/1128/console the tests finished with:

[error] Interrupted waiting for command to finish (java -Xms64M -Xmx1024M ...)
[info] Thread pool timeout elapsed before all tests were complete!!!
646 - run/t6253a.scala                          [non-zero exit code]
[info] 
[info] 1504/1505 passed, 1 skipped (elapsed time: 04:11:41)
[info] Test Run PASSED
[success] Total time: 15105 s, completed Feb 23, 2016 4:00:29 PM

which means that from the github ui this failure is completely silent.

--dryrun

Sometimes I don't have time for the run tests to complete locally, but it would be nice to at least compile them before asking Jenkins to give it a run. I propose --dryrun to mean compile-only the executable tests, run and jvm.

Mistyped test name shouldn't test the world

That thing where it filters out non-tests and if there's nothing left, runs all tests? Really annoying when I happen to mistype. Some paths do look especially like tests, so if one of those is not an existing file, then please don't test the world.

Current dir is on classpath during `run` test

It looks like cwd is on the classpath when partest runs. A REPL test fails because it tries to run method test imported from a previous line (under tweaked name binding). Presumably test package is introduced by ./test/files.

scala> for (i <- 1 to 8) test(i)
<console>:16: error: reference to test is ambiguous;
it is both defined in package <root> and imported subsequently by
import test
       for (i <- 1 to 8) test(i)
                         ^

Checkfiles are not properly preprocessed when diffing

Under --show-diff, things like these happen:

!! 1 - neg/t7494-no-options                      [output differs]
% diff /Users/tschlatt/Documents/scala-js/scalalib/fetchedSources/2.11.2/test/files/neg/t7494-no-options-neg.log /Users/tschlatt/Documents/scala-js/partest-suite/target/scala-2.11/test-classes/scala/tools/partest/scalajs/2.11.2/neg/t7494-no-options.check
@@ -5,27 +5,36 @@ error: Error: ploogin takes no options
          namer   2  resolve names, attach symbols to named trees
 packageobjects   3  load package objects
          typer   4  the meat and potatoes: type the trees
-     jsinterop   5  
-        patmat   6  translate match expressions
-superaccessors   7  add super accessors in traits and nested classes
-    extmethods   8  add extension methods for inline classes
-       pickler   9  serialize symbol tables
-     refchecks  10  reference/override checking, translate nested objects
-       uncurry  11  uncurry, translate function values to anonymous classes
-     tailcalls  12  replace tail calls by jumps
-    specialize  13  @specialized-driven class and method specialization
- explicitouter  14  this refs to outer pointers
-       erasure  15  erase types, add interfaces for traits
-   posterasure  16  clean up erased inline classes
-      lazyvals  17  allocate bitmaps, translate lazy vals into lazified defs
-    lambdalift  18  move nested functions to top level
-  constructors  19  move field definitions into constructors
-       flatten  20  eliminate inner classes
-         mixin  21  mixin composition
-        jscode  22  
-       cleanup  23  platform-specific cleanups, generate reflective calls
-    delambdafy  24  remove lambdas
-         icode  25  generate portable intermediate code
-           jvm  26  generate JVM bytecode
-       ploogin  27  A sample phase that does so many things it's kind of hard...
-      terminal  28  the last phase during a compilation run
+        patmat   5  translate match expressions
+superaccessors   6  add super accessors in traits and nested classes
+    extmethods   7  add extension methods for inline classes
+       pickler   8  serialize symbol tables
+     refchecks   9  reference/override checking, translate nested objects
+       uncurry  10  uncurry, translate function values to anonymous classes
+     tailcalls  11  replace tail calls by jumps
+    specialize  12  @specialized-driven class and method specialization
+ explicitouter  13  this refs to outer pointers
+       erasure  14  erase types, add interfaces for traits
+   posterasure  15  clean up erased inline classes
+      lazyvals  16  allocate bitmaps, translate lazy vals into lazified defs
+    lambdalift  17  move nested functions to top level
+  constructors  18  move field definitions into constructors
+       flatten  19  eliminate inner classes
+         mixin  20  mixin composition
+       cleanup  21  platform-specific cleanups, generate reflective calls
+    delambdafy  22  remove lambdas
+         icode  23  generate portable intermediate code
+#partest !-optimise
+           jvm  24  generate JVM bytecode
+       ploogin  25  A sample phase that does so many things it's kind of hard...
+      terminal  26  the last phase during a compilation run
+#partest -optimise
+       inliner  24  optimization: do inlining
+inlinehandlers  25  optimization: inline exception handlers
+      closelim  26  optimization: eliminate uncalled closures
+      constopt  27  optimization: optimize null and other constants
+           dce  28  optimization: eliminate dead code
+           jvm  29  generate JVM bytecode
+       ploogin  30  A sample phase that does so many things it's kind of hard...
+      terminal  31  the last phase during a compilation run
+#partest

Note the #partest lines. They should be processed just like when comparing, before doing the diff.

Drop scala-xml dependency?

In scala/scala#6436, scala-xml was dropped from the scala compiler build.

Turns out, when the compiler bootstrap script tries to build partest it fails to find a scala-xml version that satisfies the scalaBinaryVersion.

However, the dependency on scala-xml here is only "provided". It's not clear why it even needs to be "provided". Removing the dependency from build.sbt, it will still compile. Usually, "provided" suggests there are code paths that require it, but the user should provide it themselves. But I'm not seeing any code paths that require scala-xml. Perhaps, there is a use case in partest that requires scala-xml that's not obvious?

If not, could the provided-dependency on scala-xml just be ripped out?

Maybe, when scala-xml was part of scaladoc (as far back as yesterday), it was important to probably sprinkle the dependency everywhere, including here.

An old comment in build.sbt hints as much:

scalap depends on scala-compiler, which depends (for the scaladoc part) on scala-xml
and scala-parser-combinators more precisely, scala-compiler_2.11.0-M5 depends on
                     scala-xml_2.11.0-M4 and
      scala-parser-combinators_2.11.0-M4,
so that we get a binary version incompatibility warning
To fix this, we'll modularize scaladoc to remove the dependency from scala-compiler-core,
and use dbuild to replicate the staged build we had originally,
so that we don't mix cross-versioned artifacts.

Integration test: run scala test suite for PR validation

In sbt:

set version := "1.0.0-local"
publishM2

Then, over in the scala/scala checkout,
edit versions.properties so that partest.version.number=1.0.0-local.
rm build/pack/partest.properties to have the build recreate the partest classpath, and run the test suite using test/partest.

speedup: don't fork a new JVM for tests that don't actually need one

Each run (and jvm) test always forks a fresh JVM; this costs a lot in startup time, and we're paying that cost about 1800 times. @retronym observes that tests that actually need this level of isolation are probably relatively few. Most of the time we should be enough to stay in partest's own JVM and just isolate each test in a fresh classloader. We'll need to capture stdout and stderr and trap System.exit.

@vpetro, @dwijnand, @retronym and I wrote wip code for this today at a Lightbend engineering retreat. Our preliminary results indicate an average overall speedup of about 2x. If that holds, this will substantially speed up PR validation.

PR to follow. It may take a while to identify tests that need the old level of isolation. (We've already seen cases where test A does something later causing test B to fail, so it isn't a trivial matter of just running any failed test the old way.)

possibly dead branches

The partest repo at the moment has the following branches

  • 1.0.x
  • 1.1.x
  • 2.12.0
  • bump-1.1.2
  • runCommand-public
  • topic/sbt-partest-read

It's not documented what these are for, and I suspect several of them could be deleted.

Use provided dependencies for library/reflect/compiler

As originally pointed out by @gkossakowski, these dependencies should not come with a partest dependency, but should instead be provided by the partest user, as partest is supposed to test the provided compiler.

@retronym explains how to do this in sbt:

libraryDependencies += "net.liftweb" %% "lift-json" % "2.4" % "provided"
You can always wield pomPostProcess on the producer side: http://www.scala-sbt.org/0.13.0/docs/Detailed-Topics/Publishing#modifying-the-generated-pom

Seems (anecdotally) that maven-ant does the right thing: http://mail-archives.apache.org/mod_mbox/maven-users/200809.mbox/%[email protected]%3E

Flags parsing doesn't do "foo bar"

The .flags file should allow

-Dscala.repl.prompt="%nevil scala> "

because otherwise it's just evil.

Why are we so terrified of parsing quoted strings? It's the third rail of parsing.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.