├── .gitignore ├── .travis.yml ├── CODE_OF_CONDUCT.md ├── README.md ├── build.sbt ├── notes ├── 2.11.8.md ├── 2.12.0.md ├── 2.12.1.md └── typelevel-4.md ├── project ├── build.properties └── plugins.sbt ├── scripts ├── decrypt-keys.sh └── publishMicrosite.sh ├── src └── main │ ├── resources │ └── microsite │ │ ├── css │ │ └── override.css │ │ ├── data │ │ └── menu.yml │ │ └── img │ │ ├── jumbotron_pattern.png │ │ ├── jumbotron_pattern2x.png │ │ ├── navbar_brand.png │ │ ├── navbar_brand2x.png │ │ ├── poster.png │ │ ├── sidebar_brand.png │ │ └── sidebar_brand2x.png │ └── tut │ └── docs │ ├── basic_structure.md │ ├── index.md │ ├── phases.md │ ├── project_structure.md │ ├── references.md │ ├── symbols.md │ ├── trees.md │ └── types.md ├── test └── files │ ├── neg │ └── t4225-neg.log │ └── pos │ └── t4225-pos.log ├── travis-deploy-key.enc └── try-typelevel-scala.sh /.gitignore: -------------------------------------------------------------------------------- 1 | # 2 | # Are you tempted to edit this file? 3 | # 4 | # First consider if the changes make sense for all, 5 | # or if they are specific to your workflow/system. 6 | # If it is the latter, you can augment this list with 7 | # entries in .git/info/excludes 8 | # 9 | # see also test/files/.gitignore 10 | # 11 | 12 | # 13 | # JARs aren't checked in, they are fetched by Ant / pull_binary_libs.sh 14 | # 15 | # We could be more concise with /lib/**/*.jar but that assumes 16 | # a late-model git. 17 | # 18 | /lib/ant/*.jar 19 | /lib/*.jar 20 | /test/files/codelib/*.jar 21 | /test/files/lib/*.jar 22 | /test/files/speclib/instrumented.jar 23 | /tools/*.jar 24 | 25 | # Developer specific Ant properties 26 | /build.properties 27 | /buildcharacter.properties 28 | 29 | # might get generated when testing Jenkins scripts locally 30 | /jenkins.properties 31 | 32 | # target directories for ant build 33 | /build 34 | /build/ 35 | /dists/ 36 | 37 | # other 38 | /out/ 39 | /bin/ 40 | /sandbox/ 41 | /.ant-targets-build.xml 42 | 43 | # eclipse, intellij 44 | /.classpath 45 | /.project 46 | /src/intellij*/*.iml 47 | /src/intellij*/*.ipr 48 | /src/intellij*/*.iws 49 | **/.cache 50 | /.idea 51 | /.settings 52 | 53 | # Standard symbolic link to build/quick/bin 54 | /qbin 55 | 56 | # Sbt's target directories 57 | /target/ 58 | /project/target/ 59 | /project/project/target/ 60 | /project/project/project/target/ 61 | /build-sbt/ 62 | 63 | # Microsite auto-sync Readme file 64 | /src/main/tut/index.md -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | language: scala 2 | sudo: false 3 | 4 | before_install: 5 | - export PATH="$PATH:./vendor/bundle" 6 | - if [ "$TRAVIS_BRANCH" = "typelevel-readme" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then bash scripts/decrypt-keys.sh; fi 7 | 8 | install: 9 | - rvm use 2.2.3 --install --fuzzy 10 | - gem update --system 11 | - gem install sass 12 | - gem install jekyll -v 3.2.1 13 | 14 | script: 15 | - sbt makeMicrosite 16 | 17 | after_success: 18 | - if [ "$TRAVIS_BRANCH" = "typelevel-readme" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then bash scripts/publishMicrosite.sh; fi 19 | 20 | branches: 21 | only: 22 | - typelevel-readme 23 | 24 | cache: 25 | directories: 26 | - $HOME/.ivy2/cache 27 | - $HOME/.sbt/boot 28 | - vendor 29 | before_cache: 30 | - find $HOME/.ivy2 -name "ivydata-*.properties" -delete 31 | - find $HOME/.sbt -name "*.lock" -delete 32 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | We are committed to providing a friendly, safe and welcoming environment for 4 | all, regardless of level of experience, gender, gender identity and expression, 5 | sexual orientation, disability, personal appearance, body size, race, 6 | ethnicity, age, religion, nationality, or other such characteristics. 7 | 8 | Everyone is expected to follow the [Scala Code of Conduct] when discussing the 9 | project on the available communication channels. If you are being harassed, 10 | please contact us immediately so that we can support you. 11 | 12 | ## Moderation 13 | 14 | Any questions, concerns, or moderation requests please contact a member of the 15 | project. 16 | 17 | - Miles Sabin: [gitter](https://gitter.im/milessabin) | [twitter](https://twitter.com/milessabin) | [email](mailto:miles@milessabin.com) 18 | 19 | [Scala Code of Conduct]: https://www.scala-lang.org/conduct/ 20 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![Build Status](https://travis-ci.org/typelevel/scala.svg?branch=typelevel-readme)](https://travis-ci.org/typelevel/scala) [![Join the chat at https://gitter.im/typelevel/scala](https://badges.gitter.im/typelevel/scala.svg)](https://gitter.im/typelevel/scala?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) 2 | 3 | # (ARCHIVED) Typelevel Scala 4 | 5 | 6 | ## What ~is~ was this repository? 7 | 8 | This [repository][tls] contains the [Typelevel][typelevel] maintained [fork][fork] of [Lightbend's][lbs] compiler for the Scala 2. 9 | 10 | Typelevel Scala was a fork of `scalac`, the compiler for the Scala 2 language. The TypeLevel fork was based on [Lightbend Scala][lbs], 11 | and it was forked as a conservative, collaborative, and binary compatible fork. 12 | Its main purpose was to prototype and deliver features, enhancements, and bugfixes, to improve the experience of those who 13 | use functional programming in Scala. 14 | 15 | In July 2019, after the release of version 2.13.0 of the Scala 2 compiler, and with Dotty (Scala 3) already in advanced state of development, 16 | the authors [concluded](https://github.com/typelevel/scala/issues/186) that the TypeLevel fork had served its purpose. 17 | New contributions are best forwarded to the [Lightbend's][lbs] compiler fork. 18 | 19 | > The way I see it, the TypeLevel compiler was very useful for trying out and refining features that have found their way into the mainline compiler afterwards. (by [Martin Odersky](https://github.com/typelevel/scala/issues/186#issuecomment-508002321) 20 | 21 | ## Relationship with Lightbend Scala 22 | 23 | Typelevel Scala releases will be made in lockstep with Lightbend Scala and will by default generate code which is 24 | binary compatible with code generated by Lightbend Scala. Code generated with Typelevel Scala can be freely linked 25 | against binary dependencies generated with Lightbend Scala and vice versa. This allows Typelevel Scala features and 26 | fixes to be used with minimal risk. 27 | 28 | The policy for inclusion of a fix or a feature in a Typelevel Scala release is as follows, 29 | 30 | + It must be first submitted as a pull request to the corresponding version of Lightbend Scala. 31 | + It must have a reasonable likelihood of being merged in a future Lightbend Scala release. 32 | + It must offer a significant fix or feature for which there is no reasonable alternative or workaround. 33 | + It must maintain binary compatibility with Lightbend Scala unless a binary change is the primary motivation for the 34 | addition. 35 | 36 | The aim of this policy is to keep Typelevel Scala as close as possible to Lightbend Scala whilst still providing 37 | significant benefits to people who are affected by the issues it addresses. The requirement that all changes exist as 38 | a pull request against Lightbend Scala _first_ and have a reasonable chance of being merged in a future Lightbend 39 | Scala release is intended to encourage collaboration and convergence between Typelevel and Lightbend Scala 40 | contributors. 41 | 42 | Apart from the first criterion there is room for interpretation — after all, what counts as "reasonable"? Where 43 | the letter of the policy is unclear we appeal to its spirit — we want access to these features and fixes in our 44 | projects _now_ and for that to be feasible it is essential that we maintain the greatest possible degree of binary 45 | interoperability with the rest of the Scala ecosystem. 46 | 47 | ## Typelevel Scala releases 48 | 49 | Typelevel Scala releases are distinguished from the corresponding Lightbend Scala releases by a version number suffix 50 | which indicates the Typelevel feature level beyond the baseline compiler. We are attempting to maintain parity of 51 | Typelevel features across the Scala compiler versions we support. 52 | 53 | The current Typelevel feature level is 4 and it is avaliable as a drop in replacement for Lightbend Scala 2.11.11, 54 | 2.12.4 and 2.13.0-M2. Full release notes are available, 55 | 56 | + Typelevel Scala 4 [2.11.11/2.12.4/2.13.0-M2](https://github.com/typelevel/scala/blob/typelevel-readme/notes/typelevel-4.md). 57 | 58 | Support for Scala 2.10.6 will be considered if sponsors step forward to support the necessary work. 59 | 60 | ## Should I use Typelevel Scala? In production? 61 | 62 | The baseline for Typelevel Scala is the corresponding version of Lightbend Scala. Every bugfix or feature addition to 63 | Typelevel Scala exists as a pull request against that Lightbend Scala version, so will have been passed by the full 64 | Scala toolchain test suite and, in most cases, will have been reviewed by the Lightbend Scala compiler team. 65 | 66 | If you are affected by one of the bugs which Typelevel Scala addresses then you will have to weigh the risks and costs 67 | of using a compiler with the bug (perhaps with workarounds using unnecessarily complex encodings, macros or compiler 68 | plugins), against the risks and costs of using an alternative Scala distribution which fixes that bug. Only you can 69 | make that call. The same considerations apply to the additional features that Typelevel Scala supports. 70 | 71 | More generally there are many reasons why you might want to use and contribute to Typelevel Scala, 72 | 73 | + You want to evaluate or contribute to a feature or fix. 74 | + You want to explore how new language features interact with existing libraries. 75 | + You want to explore new library designs enabled by new language features. 76 | + You want to propose new language features motiviated by your experiences with library design. 77 | + You want to contribute a feature or fix to Lightbend/Typelevel Scala and want to evaluate its interactions with 78 | other pending features and fixes. 79 | 80 | Within the Typelevel family of projects we are particularly excited by the prospect of being able to coevolve 81 | libraries along with the language and believe that this is one of the best ways to keep the language fresh and 82 | relevant to practitioners. 83 | 84 | ## Try Typelevel Scala with an Ammonite instant REPL 85 | 86 | The quickest way to get to a Typelevel Scala 2.12.4 REPL path is to run the provided 87 | ["try Typelevel Scala"][try-tls] script, which has no dependencies other than an installed JDK. This script 88 | downloads and installs [coursier][coursier] and uses it to fetch the [Ammonite][ammonite] REPL and Typelevel Scala 89 | 2.12.4. It then drops you immediately into a REPL session, 90 | 91 | ```text 92 | % curl -s https://raw.githubusercontent.com/typelevel/scala/typelevel-readme/try-typelevel-scala.sh | bash 93 | Loading... 94 | Compiling (synthetic)/ammonite/predef/interpBridge.sc 95 | Compiling (synthetic)/ammonite/predef/replBridge.sc 96 | Compiling (synthetic)/ammonite/predef/DefaultPredef.sc 97 | Welcome to the Ammonite Repl 1.0.1 98 | (Scala 2.12.4-bin-typelevel-4 Java 1.8.0_144) 99 | If you like Ammonite, please support our development at www.patreon.com/lihaoyi 100 | @ repl.compiler.settings.YliteralTypes.value = true 101 | 102 | 103 | @ trait Cond[T] { type V ; val value: V } 104 | defined trait Cond 105 | 106 | @ implicit val condTrue = new Cond[true] { type V = String ; val value = "foo" } 107 | condTrue: AnyRef with Cond[true]{type V = String} = ammonite.$sess.cmd2$$anon$1@696a6506 108 | 109 | @ implicit val condFalse = new Cond[false] { type V = Int ; val value = 23 } 110 | condFalse: AnyRef with Cond[false]{type V = Int} = ammonite.$sess.cmd3$$anon$1@461e9b31 111 | 112 | @ def cond[T](implicit cond: Cond[T]): cond.V = cond.value 113 | defined function cond 114 | 115 | @ cond[true] : String 116 | res5: String = "foo" 117 | 118 | @ cond[false] : Int 119 | res6: Int = 23 120 | 121 | @ Bye! 122 | % 123 | ``` 124 | 125 | [try-tls]: https://github.com/typelevel/scala/blob/typelevel-readme/try-typelevel-scala.sh 126 | [coursier]: https://github.com/coursier/coursier 127 | [ammonite]: https://github.com/lihaoyi/Ammonite 128 | 129 | ## How to use Typelevel Scala 4 with SBT 130 | 131 | Requirements for using Typelevel Scala in your existing projects, 132 | 133 | + You must be using Lightbend Scala 2.11.11, 2.12.4 or 2.13.0-M2. 134 | + You must be using SBT 0.13.15 or later. 135 | + Your build should use `scalaOrganization.value` and `CrossVersion.patch` appropriately. 136 | 137 | You can find many examples linked to from [this issue][build-tweaks-1]. 138 | + (Optional) Your build should scope `scalaVersion` to `ThisBuild`. 139 | 140 | You can find an example in [the shapeless build][build-tweaks-2], 141 | 142 | ``` 143 | inThisBuild(Seq( 144 | organization := "com.chuusai", 145 | scalaVersion := "2.12.4", 146 | crossScalaVersions := Seq("2.10.6", "2.11.11", "2.12.4", "2.13.0-M2") 147 | )) 148 | ``` 149 | 150 | You can now temporarily build with Typelevel Scala by entering, 151 | 152 | ``` 153 | > ; set every scalaOrganization := "org.typelevel" ; ++2.12.4-bin-typelevel-4 154 | ``` 155 | 156 | on the SBT REPL. 157 | 158 | To switch your project permanently to Typelevel Scala 4 update your `build.sbt` as follows, 159 | 160 | ``` 161 | inThisBuild(Seq( 162 | scalaOrganization := "org.typelevel", 163 | scalaVersion := "2.12.4-bin-typelevel-4" 164 | )) 165 | ``` 166 | 167 | Alternatively, if you want to try Typelevel Scala without modifying your `build.sbt` and you have scoped 168 | `scalaVersion` as shown earlier you can instead create a file `local.sbt` at the root of your project with the 169 | following content, 170 | 171 | ``` 172 | inThisBuild(Seq( 173 | scalaOrganization := "org.typelevel", 174 | scalaVersion := "2.12.4-bin-typelevel-4" 175 | )) 176 | ``` 177 | 178 | These settings will override the `ThisBuild` scoped settings in your `build.sbt`. 179 | 180 | Whichever method you choose, your build should now function as before but using the Typelevel Scala toolchain instead 181 | of the Lightbend one. You can verify that the settings have been updated correctly from the SBT prompt using `show`, 182 | 183 | ``` 184 | > show scalaOrganization 185 | [info] org.typelevel 186 | > show scalaVersion 187 | [info] 2.12.4-bin-typelevel-4 188 | ``` 189 | 190 | [build-tweaks-1]: https://github.com/typelevel/scala/issues/135 191 | [build-tweaks-2]: https://github.com/milessabin/shapeless/blob/master/build.sbt#L13-L17 192 | 193 | ## How to use Typelevel Scala 4 with Maven 194 | 195 | If you are using maven with the `scala-maven-plugin`, set the `` to `org.typelevel`, 196 | 197 | ``` 198 | 199 | net.alchim31.maven 200 | scala-maven-plugin 201 | 3.2.1 202 | 203 | org.typelevel 204 | 2.12.4-bin-typelevel-4 205 | 206 | 207 | ``` 208 | 209 | ## Roadmap 210 | 211 | The following are high priority issues for Typelevel projects on which progress is likely to be made in 2017, 212 | 213 | + Partial type application 214 | + Multiple implicit parameter blocks 215 | + ~~Improved compile times for inductive implicits~~ — **Done** 216 | + Improved control over implicit prioritization 217 | + ~~Improved error reporting for implicit resolution failures~~ — **Done** 218 | + GADT and singleton type bugfixes. 219 | + Literal syntax for Byte and Short types. 220 | + ~~Support for alternative `scala.Predef`~~ — **Done** 221 | 222 | In accordance with the policy for inclusion contributions on these issues will be made as pull requests against 223 | Lightbend Scala in the first instance. 224 | 225 | ## How to contribute to Typelevel Scala 226 | 227 | Because of our policy of "pull request against Lightbend Scala first" the primary route to contributing to Typelevel 228 | Scala is by contributing to Lightbend Scala. The Lightbend Scala team have made huge advances in lowering the barrier 229 | to participation in compiler development recently, in large part due to a new SBT-based build, and [helpful 230 | documentation][lbs-readme] — the Scala distribution is now an SBT project which you can expect to work on in 231 | much the same way as any other github hosted FLOSS Scala project. [Miles Sabin][milessabin] has provided a write up 232 | (now slightly outdated) of the process [here][scalac-post]. 233 | 234 | Because a pull request against [scala/scala][lbs] is the first step, to contribute you will need to sign the [Scala 235 | CLA][scala-cla] and be willing to make your contributions under the [Scala License][scala-license]. Typelevel is 236 | strongly in favour of the currently Scala license/CLA (which requires contributors to grant a patent license but does 237 | not grant one in return) being replaced by the Apache 2.0 [license][apache-2.0-license] and [ICLA][apache-2.0-icla] 238 | (which both requires and grants a patent license) as soon as is feasible. If you would like to contribute but are 239 | unable to sign the CLA please raise this issue on the [Lightbend][lbs-gitter] and [Typelevel][tls-gitter] gitter 240 | channels. 241 | 242 | ## Community 243 | 244 | Topics specific to Typelevel Scala are discussed on its [gitter channel][tls-gitter]. Scala compiler development is 245 | discussed on the [scala/contributors gitter channel][lbs-gitter]. 246 | 247 | People are expected to follow the [Scala Code of Conduct][coc] when discussing Typelevel Scala on the Github page, 248 | Gitter channel, or other venues. 249 | 250 | We hope that our community will be respectful, helpful, and kind. If you find yourself embroiled in a situation that 251 | becomes heated, or that fails to live up to our expectations, you should disengage and contact one of the [project 252 | maintainers](#maintainers) in private. We hope to avoid letting minor aggressions and misunderstandings escalate into 253 | larger problems. 254 | 255 | If you are being harassed, please contact one of [us](#maintainers) immediately so that we can support you. 256 | 257 | ## Maintainers 258 | 259 | The current maintainers (people who can merge pull requests) are: 260 | 261 | + Erik Osheim ([@non](https://github.com/non)) 262 | + George Leontiev ([@folone](https://github.com/folone)) 263 | + Jon Pretty ([@propensive](https://github.com/propensive)) 264 | + Lars Hupel ([@larsrh](https://github.com/larsrh)) 265 | + Miles Sabin ([@milessabin](https://github.com/milessabin)) 266 | + Tom Switzer ([@tixxit](https://github.com/tixxit)) 267 | 268 | [tls]: https://github.com/typelevel/scala 269 | [fork]: http://typelevel.org/blog/2014/09/02/typelevel-scala.html 270 | [lbs]: https://github.com/scala/scala 271 | [projects]: http://typelevel.org/projects/ 272 | [tls-gitter]: https://gitter.im/typelevel/scala 273 | [lbs-gitter]: https://gitter.im/scala/contributors 274 | [typelevel]: http://typelevel.org/ 275 | [coc]: https://www.scala-lang.org/conduct/ 276 | [lbs-readme]: https://github.com/scala/scala/blob/2.12.x/README.md 277 | [scalac-post]: http://milessabin.com/blog/2016/05/13/scalac-hacking/ 278 | [milessabin]: https://github.com/milessabin 279 | [scala-cla]: http://www.lightbend.com/contribute/cla/scala 280 | [scala-license]: https://github.com/scala/scala/blob/2.12.x/doc/LICENSE.md 281 | [apache-2.0-license]: http://www.apache.org/licenses/LICENSE-2.0 282 | [apache-2.0-icla]: https://www.apache.org/licenses/icla.txt 283 | -------------------------------------------------------------------------------- /build.sbt: -------------------------------------------------------------------------------- 1 | import microsites._ 2 | 3 | name := "Scala" 4 | version := "1.0" 5 | scalaVersion := "2.11.8" 6 | 7 | micrositeName := "Typelevel" 8 | micrositeDescription := "Our fork of the Scala compiler" 9 | micrositeAuthor := "Typelevel contributors" 10 | micrositeHomepage := "http://typelevel.org/scala/" 11 | micrositeGithubOwner := "typelevel" 12 | micrositeGithubRepo := "scala" 13 | micrositeBaseUrl := "scala" 14 | micrositeDocumentationUrl := "docs/" 15 | micrositeExtraMdFiles := Map( 16 | file("README.md") -> ExtraMdFileConfig( 17 | "index.md", 18 | "home" 19 | ) 20 | ) 21 | micrositeHighlightTheme := "atom-one-light" 22 | micrositePalette := Map( 23 | "brand-primary" -> "#FC4053", 24 | "brand-secondary" -> "#B92239", 25 | "brand-tertiary" -> "#8C192F", 26 | "gray-dark" -> "#464646", 27 | "gray" -> "#7E7E7E", 28 | "gray-light" -> "#E8E8E8", 29 | "gray-lighter" -> "#F6F6F6", 30 | "white-color" -> "#FFFFFF") 31 | 32 | enablePlugins(MicrositesPlugin) 33 | -------------------------------------------------------------------------------- /notes/2.11.8.md: -------------------------------------------------------------------------------- 1 | # Typelevel Scala 2.11.8 2 | 3 | The Typelevel Scala additions to Lightbend Scala 2.11.8 can be found on the branch 4 | [2.11.8-bin-typelevel][2.11.8-bin-typelevel] of this repository. 5 | 6 | Typelevel Scala 2.11.8 offers the following fixes and features over Lightbend Scala 2.11.8, 7 | 8 | + Support for partial unification (ie. a fix for [SI-2712][SI-2712]) — merged in Lightbend Scala 2.12.0-RC1 and 9 | 2.11.9 10 | 11 | An improvement to type inference for type constructors, enabled by the `-Ypartial-unification` scalac option. This 12 | has many benefits for libraries, such as Cats and Scalaz, which make extensive use of higher-kinded types. 13 | 14 | Full details on the [pull request][pr-2712]. 15 | + Support for literal types (aka SIP-23) — proposed for Lightbend Scala 2.12.1. 16 | 17 | Implements [literal types][SIP-23]. Enabled by `-Yliteral-types`. 18 | 19 | Literals can now appear in type position, designating the corresponding singleton type. A `scala.ValueOf[T]` type 20 | class and corresponding `scala.Predef.valueOf[T]` operator has been added yielding the unique value of types with a 21 | single inhabitant. Support for `scala.Symbol` literal types has been added. 22 | + A partial fix for SI-7046 — proposed for Lightbend Scala 2.12.1 and merged in 2.11.9. 23 | 24 | The macro API call `knownDirectSubclasses` now yields the correct result in most cases and will report an error in 25 | cases where it is unable to yield the correct result. 26 | 27 | This is only a partial fix because subclasses defined in local scopes might be missed by `knownDirectSubclasses`. In 28 | mitigation it is very likely that a local subclass would represent an error in any scenario where 29 | `knownDirectSubclasses` might be used. An error will be reported in these cases. 30 | 31 | Full details on the [pull request][pr-7046]. 32 | + A fix for SI-9760 — merged in Lightbend Scala 2.12.0-RC1 and 2.11.9. 33 | 34 | Higher kinded type arguments are now refined by GADT pattern matching. Details can be found on [the 35 | ticket][SI-9760]. 36 | 37 | Note that Typelevel Scala 2.11.8 and Lightbend Scala 2.11.11 replace the [si2712fix compiler plugin][si2712fix-plugin] — 38 | if you are using it you should remove it from your build before switching to either of these compilers. 39 | 40 | ## How to use Typelevel Scala 2.11.8 with SBT 41 | 42 | There are two requirements for using Typelevel Scala in your existing projects, 43 | 44 | + You must be using (or be able to switch to) Lightbend Scala 2.11.8. 45 | + You must be using (or be able to switch to) SBT 0.13.13 or later. Earlier versions of SBT don't have full support 46 | for using an alternative `scalaOrganization`. 47 | 48 | If these conditions are met the following steps will build your project with Typelevel Scala, 49 | 50 | + Ensure that your `project/build.properties` specifies SBT 0.13.13, 51 | 52 | ``` 53 | sbt.version=0.13.13 54 | ``` 55 | 56 | + Add the following to your `build.sbt` immediately next to where you set `scalaVersion`, 57 | 58 | ``` 59 | scalaOrganization in ThisBuild := "org.typelevel" 60 | ``` 61 | 62 | Alternatively, if you want to try Typelevel Scala without modifying your `build.sbt` you can instead create a file 63 | `local.sbt` at the root of your project with the following content, 64 | 65 | ``` 66 | scalaOrganization in ThisBuild := "org.typelevel" 67 | ``` 68 | 69 | This will be merged with your main build definitions and can be added to `.gitignore` or `.git/info/exclude` if so 70 | desired. 71 | 72 | Now your build should function as before but using the Typelevel Scala toolchain instead of the Lightbend one. You can 73 | verify this from the SBT prompt, 74 | 75 | ``` 76 | > show scalaOrganization 77 | [info] org.typelevel 78 | > 79 | ``` 80 | 81 | ## How to use Typelevel Scala 2.11.8 with Maven 82 | 83 | If you are using maven with the `scala-maven-plugin`, set the `` to `org.typelevel`, 84 | 85 | ``` 86 | 87 | net.alchim31.maven 88 | scala-maven-plugin 89 | 3.2.1 90 | 91 | org.typelevel 92 | 93 | 94 | ``` 95 | 96 | [SI-2712]: https://issues.scala-lang.org/browse/SI-2712 97 | [pr-2712]: https://github.com/scala/scala/pull/5102 98 | [SI-7046]: https://issues.scala-lang.org/browse/SI-7046 99 | [pr-7046]: https://github.com/scala/scala/pull/5284 100 | [SI-9760]: https://issues.scala-lang.org/browse/SI-9760 101 | [SIP-23]: https://github.com/scala/scala/pull/5310 102 | [2.11.8-bin-typelevel]: https://github.com/typelevel/scala/commits/2.11.8-bin-typelevel 103 | [si2712fix-plugin]: https://github.com/milessabin/si2712fix-plugin 104 | -------------------------------------------------------------------------------- /notes/2.12.0.md: -------------------------------------------------------------------------------- 1 | # Typelevel Scala 2.12.0 2 | 3 | The Typelevel Scala additions to Lightbend Scala 2.12.0 can be found on the branch 4 | [2.12.0-bin-typelevel][2.12.0-bin-typelevel] of this repository. 5 | 6 | Typelevel Scala 2.12.0 offers the following fixes and features over Lightbend Scala 2.12.0, 7 | 8 | + Support for literal types (aka SIP-23) — proposed for Lightbend Scala 2.12.1. 9 | 10 | Implements [literal types][SIP-23]. Enabled by `-Yliteral-types`. 11 | 12 | Literals can now appear in type position, designating the corresponding singleton type. A `scala.ValueOf[T]` type 13 | class and corresponding `scala.Predef.valueOf[T]` operator has been added yielding the unique value of types with a 14 | single inhabitant. Support for `scala.Symbol` literal types has been added. 15 | + A partial fix for SI-7046 — proposed for Lightbend Scala 2.12.1. 16 | 17 | The macro API call `knownDirectSubclasses` now yields the correct result in most cases and will report an error in 18 | cases where it is unable to yield the correct result. 19 | 20 | This is only a partial fix because subclasses defined in local scopes might be missed by `knownDirectSubclasses`. In 21 | mitigation it is very likely that a local subclass would represent an error in any scenario where 22 | `knownDirectSubclasses` might be used. An error will be reported in these cases. 23 | 24 | Full details on the [pull request][pr-7046]. 25 | 26 | The following have already been merged in Lightbend Scala 2.12.x and so are included here automatically, 27 | 28 | + Support for partial unification (ie. a fix for [SI-2712][SI-2712]) — merged in Lightbend Scala 2.12.0-RC1. 29 | 30 | An improvement to type inference for type constructors, enabled by the `-Ypartial-unification` scalac option. This 31 | has many benefits for libraries, such as Cats and Scalaz, which make extensive use of higher-kinded types. 32 | 33 | Full details on the [pull request][pr-2712]. 34 | + A fix for SI-9760 — merged in Lightbend Scala 2.12.0-RC1. 35 | 36 | Higher kinded type arguments are now refined by GADT pattern matching. Details can be found on [the 37 | ticket][SI-9760]. 38 | 39 | ## How to use Typelevel Scala 2.12.0 with SBT 40 | 41 | There are two requirements for using Typelevel Scala in your existing projects, 42 | 43 | + You must be using (or be able to switch to) Lightbend Scala 2.12.0. 44 | + You must be using (or be able to switch to) SBT 0.13.13 or later. Earlier versions of SBT don't have full support 45 | for using an alternative `scalaOrganization`. 46 | 47 | If these conditions are met the following steps will build your project with Typelevel Scala, 48 | 49 | + Ensure that your `project/build.properties` specifies SBT 0.13.13, 50 | 51 | ``` 52 | sbt.version=0.13.13 53 | ``` 54 | 55 | + Add the following to your `build.sbt` immediately next to where you set `scalaVersion`, 56 | 57 | ``` 58 | scalaOrganization in ThisBuild := "org.typelevel" 59 | ``` 60 | 61 | Alternatively, if you want to try Typelevel Scala without modifying your `build.sbt` you can instead create a file 62 | `local.sbt` at the root of your project with the following content, 63 | 64 | ``` 65 | scalaOrganization in ThisBuild := "org.typelevel" 66 | ``` 67 | 68 | This will be merged with your main build definitions and can be added to `.gitignore` or `.git/info/exclude` if so 69 | desired. 70 | 71 | Now your build should function as before but using the Typelevel Scala toolchain instead of the Lightbend one. You can 72 | verify this from the SBT prompt, 73 | 74 | ``` 75 | > show scalaOrganization 76 | [info] org.typelevel 77 | > 78 | ``` 79 | 80 | ## How to use Typelevel Scala 2.12.0 with Maven 81 | 82 | If you are using maven with the `scala-maven-plugin`, set the `` to `org.typelevel`, 83 | 84 | ``` 85 | 86 | net.alchim31.maven 87 | scala-maven-plugin 88 | 3.2.1 89 | 90 | org.typelevel 91 | 92 | 93 | ``` 94 | 95 | [SI-2712]: https://issues.scala-lang.org/browse/SI-2712 96 | [pr-2712]: https://github.com/scala/scala/pull/5102 97 | [SI-7046]: https://issues.scala-lang.org/browse/SI-7046 98 | [pr-7046]: https://github.com/scala/scala/pull/5284 99 | [SI-9760]: https://issues.scala-lang.org/browse/SI-9760 100 | [SIP-23]: https://github.com/scala/scala/pull/5310 101 | [2.12.0-bin-typelevel]: https://github.com/typelevel/scala/commits/2.12.0-bin-typelevel 102 | -------------------------------------------------------------------------------- /notes/2.12.1.md: -------------------------------------------------------------------------------- 1 | # Typelevel Scala 2.12.1 2 | 3 | We are pleased to announce the availability of [Typelevel][typelevel] [Scala][tls] 2.12.1! 4 | 5 | ## Additonal features included in TLS 2.12.1 6 | 7 | The Typelevel Scala additions to Lightbend Scala 2.12.1 can be found on the branch 8 | [2.12.1-bin-typelevel][2.12.1-bin-typelevel] of this repository. 9 | 10 | Typelevel Scala 2.12.1 offers the features listed below over Lightbend Scala 2.12.1. Following [Typelevel Scala 11 | policy][merge-policy] each one of these exists as a pull request against Lightbend Scala and is being considered for 12 | merging. 13 | 14 | Please report issues with the new features on the [TLS][tls] github repo issue tracker or directly on the 15 | corresponding LBS pull request. Discussion can be found on the TLS [gitter channel][tls-gitter]. More general Scala 16 | compiler development discussion can be found on [`scala/contributors`][lbs-gitter]. 17 | 18 | **TL;DR** ... [skip ahead](#how-to-use-typelevel-scala-2121) to instructions on how to use in your project! 19 | 20 | ### Faster compilation of inductive implicits ([pull/5649][pr-inductive-implicits], [@milessabin][milessabin]) 21 | 22 | Enabled by `-Yinduction-heuristics`, this feature dramatically speeds up the compilation of inductive implicit 23 | resolution, such as is found in [shapeless][shapeless]-based generic programming and type class derivation. 24 | 25 | The following is an example of the sort of inductive definition which will benefit from this feature, 26 | 27 | ```scala 28 | @annotation.inductive 29 | trait Selector[L <: HList, U] { 30 | def apply(l: L): U 31 | } 32 | 33 | object Selector { 34 | def apply[L <: HList, U](implicit selector: Selector[L, U]): Selector[L, U] = selector 35 | 36 | // Base case for induction 37 | implicit def inHead[H, T <: HList]: Selector[H :: T, H] = 38 | new Selector[H :: T, H] { 39 | def apply(l : H :: T) = l.head 40 | } 41 | 42 | // Induction set: instance requires a smaller instance of the same type class 43 | implicit def inTail[H, T <: HList, U] 44 | (implicit st : Selector[T, U]): Selector[H :: T, U] = 45 | new Selector[H :: T, U] { 46 | def apply(l : H :: T) = st(l.tail) 47 | } 48 | } 49 | ``` 50 | 51 | `Selector` extracts elements from values of `HList` types in a type safe way. Without this feature enabled 52 | materializing instances of this type class are roughly cubic in the length of the `HList`. With this feature 53 | enabled the behaviour is close to linear and with a small constant factor. A benchmark demonstrating a 36x speedup for 54 | selection from a 500 element `HList` can be found [here][induction-benchmark]. 55 | 56 | One current limitation is that where the induction step is wrapped in shapeless's `Lazy` the induction will not take 57 | advantage of this algorithm. In some cases it may be possible to drop the use of `Lazy`, though not all. Later TLS 58 | releases will provide an interpretation of byname implicit arguments which is equivalent to shapeless's `Lazy` and 59 | which will get along nicely with this induction heuristic. 60 | 61 | More details on the [PR][pr-inductive-implicits]. 62 | 63 | ### Minimal kind-polymorphism ([pull/5538][pr-kind-polymorphism], [@mandubian][mandubian]) 64 | 65 | Enabled by `-Ykind-polymorphism`, it is now possible to write type and method definitions with type parameters of 66 | arbitrary kinds. 67 | 68 | The following is an example of a type class which is indexed by types of arbitrary kinds, 69 | 70 | ```scala 71 | trait Foo[T <: AnyKind] { type Out ; def id(t: Out): Out = t } 72 | 73 | object Foo { 74 | implicit def foo0[T] = new Foo[T] { type Out = T } 75 | implicit def foo1[T[_]] = new Foo[T] { type Out = T[Any] } 76 | implicit def foo2[T[_, _]] = new Foo[T] { type Out = T[Any, Any] } 77 | } 78 | 79 | def foo[T <: AnyKind](implicit f: Foo[T]): f.type = f 80 | 81 | foo[Int].id(23) 82 | foo[List].id(List[Any](1, 2, 3)) 83 | foo[Map].id(Map[Any, Any](1 -> "toto", 2 -> "tata", 3 -> "tutu")) 84 | ``` 85 | 86 | The special type `AnyKind` is used as a bound to indicate that a type variable may be instantiated by a type argument 87 | of any kind. Instances of the type class are then provided for types of kind `*`, kind `* -> *` and kind `* -> * -> *`. 88 | 89 | More examples can be found [here][kind-poly-examples]. 90 | 91 | More details on the [PR][pr-kind-polymorphism]. 92 | 93 | ### Configurable default imports ([pull/5350][pr-default-imports], [@andyscott][andyscott]) 94 | 95 | Enabled by `-Ysysdef` and `-Ypredef`, it is now possible to specify the default imports for a Scala compilation 96 | allowing, for example, an alternative `Predef` to be used. 97 | 98 | By default, scalac imports `java.lang._`, `scala._`, and `scala.Predef._` into the namespace of Scala compilation 99 | units. In Lightbend Scala, we have two flags that adjust the behavior of predefined imports. 100 | 101 | + `-Yno-imports` disables all of these. 102 | + `-Yno-predef` disables `scala.Predef._`. 103 | 104 | There are a few other nuances to the behavior of imports. The most important behavior is that `scala.Predef._` is 105 | unimported/evicted if there are any direct leading imports for anything within `scala.Predef`. For example, an import 106 | of `scala.Predef.DummyImplicit` will cause everything else normally imported by predef to be unimported. 107 | 108 | This feature introduces the notion of "sysdefs" and "predefs" for Scala compilation units. Sysdefs are global imports 109 | that are imported at the top of all Scala compilation units under all circumstances. Predefs are imported after 110 | sysdefs and can be masked by top level imports in the source file (to match the existing behavior of directly 111 | importing from scala.Predef). 112 | 113 | It adds, 114 | 115 | + `-Ysysdef` which controls the global sysdef imports for all Scala compilation units. The default value is set to 116 | `java.lang._; scala._`. 117 | + `-Ypredef` which controls the predef imports for Scala compilation units. The default value is set to 118 | `scala.Predef._`. 119 | 120 | More details on the [PR][pr-default-imports]. 121 | 122 | ### Infix type printing ([pull/5589][pr-infix-types], [@allisonhb][allisonhb]) 123 | 124 | Two-parameter types with symbolic names now print in infix form by default. A `@showAsInfix` annotation has been added 125 | to enable or disable that behaviour explicitly for specific types. 126 | 127 | This provides much easier to read type signatures in the Scala REPL and elsewhere with libraries such as shapeless 128 | which make heavy use of infix type constructors, 129 | 130 | ```scala 131 | scala> import shapeless._ 132 | import shapeless._ 133 | 134 | scala> case class Foo(i: Int, s: String) 135 | defined class Foo 136 | 137 | scala> val foo = Foo(23, "foo") 138 | foo: Foo = Foo(23,foo) 139 | 140 | scala> Generic[Foo].to(foo) 141 | res0: Int :: String :: shapeless.HNil = 23 :: foo :: HNil 142 | ``` 143 | 144 | More details on the [PR][pr-infix-types]. 145 | 146 | ### Trailing commas ([pull/5245][pr-trailing-commas], [@dwijnand][dwijnand]) 147 | 148 | Comma separated lists are now allowed to have a trailing comma. This applies to tuples, argument and parameter groups 149 | and import selectors. 150 | 151 | The features makes adding and removing elements from multiline parameter lists a lot less laborious. For example, the 152 | following is now legal, 153 | 154 | ```scala 155 | trait SimpleExpr1 { 156 | def f: (Int, String) = ( 157 | 23, 158 | "bar", 159 | ) 160 | 161 | // the Tuple1 value case, the trailing comma is ignored so the type is Int and the value 23 162 | def g: Int = ( 163 | 23, 164 | ) 165 | } 166 | 167 | trait TypeArgs { 168 | class C[A, B] 169 | def f: C[ 170 | Int, 171 | String, 172 | ] 173 | } 174 | ``` 175 | 176 | More examples can be found [here][trailing-comma-examples]. 177 | 178 | More details on the [PR][pr-trailing-commas]. 179 | 180 | ### Literal types ([pull/5310][pr-literal-types], [@milesabin][milessabin]) 181 | 182 | Enabled by `-Yliteral-types`, this implements [SIP-23][sip-23]. Literals can now appear in type position, designating 183 | the corresponding singleton type. A `scala.ValueOf[T]` type class and corresponding `scala.Predef.valueOf[T]` operator 184 | has been added yielding the unique value of types with a single inhabitant. Support for `scala.Symbol` literal types 185 | has been added. 186 | 187 | Literal types have many applications in situations where a type can be specified more precisely in terms of a literal 188 | value. The following example defines the type of integers modulo some `M`. 189 | 190 | ```scala 191 | case class Residue[M <: Int](n: Int) extends AnyVal { 192 | def +(rhs: Residue[M])(implicit m: ValueOf[M]): Residue[M] = 193 | Residue((this.n + rhs.n) % valueOf[M]) 194 | } 195 | 196 | val fiveModTen = Residue[10](5) 197 | val nineModTen = Residue[10](9) 198 | 199 | fiveModTen + nineModTen // OK == Residue[10](4) 200 | 201 | val fourModEleven = Residue[11](4) 202 | 203 | //fiveModTen + fourModEleven // compiler error: type mismatch; 204 | // found : Residue[11] 205 | // required: Residue[10] 206 | ``` 207 | 208 | Because the modulus is specified by a literal type it can be checked at compile time and has no runtime storage cost. 209 | Literal types for `String`s and `Symbol`s also greatly simplify type signatures when working with shapeless records. 210 | 211 | More details on the [PR][pr-literal-types]. 212 | 213 | ### Exhaustivity of extractors, guards, and unsealed traits ([pull/5617][pr-exhaustivity], [@sellout][sellout]) 214 | 215 | Enabled by `-Xstrict-patmat-analysis`, the feature provides more accurate reporting of failures of match 216 | exhaustivity for patterns with guards or extractors. Additionally, `-Xlint:strict-unsealed-patmat` will warn on 217 | inexhaustive matches against unsealed traits. 218 | 219 | The following will now warn that the match might not be exhaustive, 220 | 221 | ```scala 222 | def nonExhaustiveIfWeAssumeGuardsFalse(x: Option[Int]): Int = x match { 223 | case Some(n) if n % 2 == 0 => n 224 | case None => 0 225 | } 226 | ``` 227 | 228 | More details on the [PR][pr-exhaustivity]. 229 | 230 | ## How to use Typelevel Scala 2.12.1 with SBT 231 | 232 | There are two requirements for using Typelevel Scala in your existing projects, 233 | 234 | + You must be using (or be able to switch to) Lightbend Scala 2.12.1. 235 | + You must be using (or be able to switch to) SBT 0.13.13 or later. Earlier versions of SBT don't have full support 236 | for using an alternative `scalaOrganization`. 237 | 238 | If these conditions are met the following steps will build your project with Typelevel Scala, 239 | 240 | + Ensure that your `project/build.properties` specifies SBT 0.13.13, 241 | 242 | ``` 243 | sbt.version=0.13.13 244 | ``` 245 | 246 | + Add the following to your `build.sbt` immediately next to where you set `scalaVersion`, 247 | 248 | ``` 249 | scalaOrganization in ThisBuild := "org.typelevel" 250 | ``` 251 | 252 | Alternatively, if you want to try Typelevel Scala without modifying your `build.sbt` you can instead create a file 253 | `local.sbt` at the root of your project with the following content, 254 | 255 | ``` 256 | scalaOrganization in ThisBuild := "org.typelevel" 257 | ``` 258 | 259 | This will be merged with your main build definitions and can be added to `.gitignore` or `.git/info/exclude` if so 260 | desired. 261 | 262 | Now your build should function as before but using the Typelevel Scala toolchain instead of the Lightbend one. You can 263 | verify this from the SBT prompt, 264 | 265 | ``` 266 | > show scalaOrganization 267 | [info] org.typelevel 268 | > 269 | ``` 270 | 271 | ## How to use Typelevel Scala 2.12.1 with Maven 272 | 273 | If you are using maven with the `scala-maven-plugin`, set the `` to `org.typelevel`, 274 | 275 | ``` 276 | 277 | net.alchim31.maven 278 | scala-maven-plugin 279 | 3.2.1 280 | 281 | org.typelevel 282 | 283 | 284 | ``` 285 | 286 | ## Known issues 287 | 288 | + The [improved exhaustivity checking](#exhaustivity-of-extractors-guards-and-unsealed-traits-pull5617-sellout) 289 | will generate warnings whether or not it is enabled. If combined with `-Xfatal-warnings` this will prevent affected 290 | projects from compiling. The warning reflects a genuine issue, however, and a fix in the affected project (handle 291 | the missing cases or add `@unchecked` as appropriate) is the right course of action. 292 | 293 | + The [kind polymorphism extension](#minimal-kind-polymorphism-pull5538-mandubian) currently allows type variable of 294 | the form `F[_<: AnyKind]` to be instantiated at non-poly-kinded type constructors, allowing ill-kinded types of such 295 | as `List[List]` to pass the type checker. This results in errors later during compilation, but the reports hard to 296 | understand. 297 | 298 | Both of these issues will be addressed in TLS 2.12.2. 299 | 300 | ## Contributors 301 | 302 | Typelevel Scala is only possible because of the contributions made to Lightbend Scala — see the contributors 303 | section of the LBS Scala 2.12.1 [release notes][lbs-2.12.1]. 304 | 305 | We are hugely grateful to the following for their work on the enhancements included in Typelevel Scala 2.12.1 and look 306 | forward to them being included in a future Lightbend Scala release, 307 | 308 | + Allison H. [@allisonhb][allisonhb] 309 | + Andy Scott [@andyscott][andyscott] 310 | + Dale Wijnand [@dwijnand][dwijnand] 311 | + Greg Pfeil [@sellout][sellout] 312 | + Miles Sabin [@milessabin][milessabin] 313 | + Pascal Voitot [@mandubian][mandubian] 314 | 315 | We would also like to thank Adriaan Moors, George Leontiev, Jason Zaugg and Vlad Ureche for their contributions to 316 | Typelevel Scala in general and to the PRs merged in this release in particular. 317 | 318 | [allisonhb]: https://github.com/allisonhb 319 | [andyscott]: https://github.com/andyscott 320 | [dwijnand]: https://github.com/dwijnand 321 | [sellout]: https://github.com/sellout 322 | [milessabin]: https://github.com/milessabin 323 | [mandubian]: https://github.com/mandubian 324 | [pr-infix-types]: https://github.com/scala/scala/pull/5589 325 | [pr-default-imports]: https://github.com/scala/scala/pull/5350 326 | [pr-trailing-commas]: https://github.com/scala/scala/pull/5245 327 | [pr-exhaustivity]: https://github.com/scala/scala/pull/5617 328 | [pr-literal-types]: https://github.com/scala/scala/pull/5310 329 | [pr-inductive-implicits]: https://github.com/scala/scala/pull/5649 330 | [pr-kind-polymorphism]: https://github.com/scala/scala/pull/5538 331 | [merge-policy]: https://github.com/typelevel/scala#relationship-with-lightbend-scala 332 | [tls]: https://github.com/typelevel/scala 333 | [lbs]: https://github.com/scala/scala 334 | [tls-gitter]: https://gitter.im/typelevel/scala 335 | [lbs-gitter]: https://gitter.im/scala/contributors 336 | [typelevel]: http://typelevel.org/ 337 | [lbs-readme]: https://github.com/scala/scala/blob/2.12.x/README.md 338 | [2.12.1-bin-typelevel]: https://github.com/typelevel/scala/commits/2.12.1-bin-typelevel 339 | [lbs-2.12.1]: https://www.scala-lang.org/news/2.12.1 340 | [sip-23]: http://docs.scala-lang.org/sips/pending/42.type.html 341 | [shapeless]: https://github.com/milessabin/shapeless 342 | [induction-benchmark]: https://github.com/typelevel/scala/blob/2.12.1-bin-typelevel/test/induction/inductive-implicits-bench.scala 343 | [kind-poly-examples]: https://github.com/typelevel/scala/blob/2.12.1-bin-typelevel/test/files/pos/kind-poly.scala 344 | [trailing-comma-examples]: https://github.com/typelevel/scala/blob/2.12.1-bin-typelevel/test/files/pos/trailing-commas.scala 345 | -------------------------------------------------------------------------------- /notes/typelevel-4.md: -------------------------------------------------------------------------------- 1 | # Typelevel Scala 4 2 | 3 | We are pleased to announce the availability of [Typelevel][typelevel] [Scala][tls] 4 for Scala 2.11.11, 2.12.4 and 4 | 2.13.0-M2. 5 | 6 | ## Typelevel Scala releases 7 | 8 | As of this release, Typelevel Scala releases are distinguished from the corresponding Lightbend Scala releases by a 9 | version number suffix which indicates the Typelevel feature level beyond the baseline compiler. We are attempting to 10 | maintain parity of Typelevel features across the Scala compiler versions we support. 11 | 12 | The current Typelevel feature level is 4 and it is avaliable as a drop in replacement for Lightbend Scala 2.11.11, 13 | 2.12.4 and 2.13.0-M2. 14 | 15 | Support for Scala 2.10.6 will be considered if sponsors step forward to support the necessary work. 16 | 17 | ## Additonal features included in TLS 4 18 | 19 | The Typelevel Scala additions to Lightbend Scala 2.11.11, 2.12.4 and 2.13.0-M2 can be found on the branches 20 | [2.11.11-bin-typelevel-4][2.11.11-bin-typelevel-4], [2.12.4-bin-typelevel-4][2.12.4-bin-typelevel-4] and 21 | respectively [2.13.0-M2-bin-typelevel-4][2.13.0-M2-bin-typelevel-4] of this repository. 22 | 23 | Typelevel Scala 4 offers the features listed below over Lightbend Scala 2.11.11/2.12.4/2.13.0-M2. Following [Typelevel 24 | Scala policy][merge-policy] each one of these exists as a pull request against Lightbend Scala and is being considered 25 | for merging. 26 | 27 | Please report issues with the new features on the [TLS][tls] github repo issue tracker or directly on the 28 | corresponding LBS pull request. Discussion can be found on the TLS [gitter channel][tls-gitter]. More general Scala 29 | compiler development discussion can be found on [`scala/contributors`][lbs-gitter]. 30 | 31 | **TL;DR** ... [skip ahead](#how-to-use-typelevel-scala-4-with-sbt) to instructions on how to use in your project! 32 | 33 | ### Type arguments on patterns ([pull/5774][pr-pattern-targs], [@paulp][paulp]) 34 | 35 | Type arguments are now allowed on patterns. This allows extractors to be parametrised by types which can be used to 36 | materialize implicits which can't be inferred from the static type of the scrutinee. As an example usage, this allows 37 | pattern matches using shapeless's [Typeable][typeable] to be expressed very succinctly, 38 | 39 | ``` 40 | object Typeable { 41 | // ... 42 | 43 | def unapply[T: Typeable](t: Any): Option[T] = t.cast[T] 44 | 45 | // ... 46 | } 47 | 48 | // Unsafe match using an erased pattern ... 49 | def unsafeToIntList(x: Any): List[Int] = x match { 50 | case xs: List[Int] => xs 51 | case _ => Nil 52 | } 53 | 54 | // Safe match using Typeable ... 55 | def safeToIntList(x: Any): List[Int] = x match { 56 | case Typeable[List[Int]](xs) => xs 57 | case _ => Nil 58 | } 59 | 60 | scala> val ints = List(1, 2, 3) 61 | ints: List[Int] = List(1, 2, 3) 62 | 63 | scala> val strings = List("foo", "bar", "baz") 64 | strings: List[String] = List(foo, bar, baz) 65 | 66 | scala> unsafeToIntList(ints) 67 | res0: List[Int] = List(1, 2, 3) 68 | 69 | scala> unsafeToIntList(strings) // Whoops! 70 | res1: List[Int] = List(foo, bar, baz) 71 | 72 | scala> res1(0) 73 | java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer 74 | at scala.runtime.BoxesRunTime.unboxToInt(BoxesRunTime.java:101) 75 | ... 39 elided 76 | 77 | scala> safeToIntList(ints) 78 | res2: List[Int] = List(1, 2, 3) 79 | 80 | scala> safeToIntList(strings) 81 | res3: List[Int] = List() 82 | ``` 83 | 84 | ### Faster compilation of inductive implicits ([pull/5649][pr-inductive-implicits], [@milessabin][milessabin]) 85 | 86 | Enabled by `-Yinduction-heuristics`, this feature dramatically speeds up the compilation of inductive implicit 87 | resolution, such as is found in [shapeless][shapeless]-based generic programming and type class derivation. 88 | 89 | The following is an example of the sort of inductive definition which will benefit from this feature, 90 | 91 | ```scala 92 | @annotation.inductive 93 | trait Selector[L <: HList, U] { 94 | def apply(l: L): U 95 | } 96 | 97 | object Selector { 98 | def apply[L <: HList, U](implicit selector: Selector[L, U]): Selector[L, U] = selector 99 | 100 | // Base case for induction 101 | implicit def inHead[H, T <: HList]: Selector[H :: T, H] = 102 | new Selector[H :: T, H] { 103 | def apply(l : H :: T) = l.head 104 | } 105 | 106 | // Induction set: instance requires a smaller instance of the same type class 107 | implicit def inTail[H, T <: HList, U] 108 | (implicit st : Selector[T, U]): Selector[H :: T, U] = 109 | new Selector[H :: T, U] { 110 | def apply(l : H :: T) = st(l.tail) 111 | } 112 | } 113 | ``` 114 | 115 | `Selector` extracts elements from values of `HList` types in a type safe way. Without this feature enabled 116 | materializing instances of this type class are roughly cubic in the length of the `HList`. With this feature 117 | enabled the behaviour is close to linear and with a small constant factor. A benchmark demonstrating a 36x speedup for 118 | selection from a 500 element `HList` can be found [here][induction-benchmark]. 119 | 120 | One current limitation is that where the induction step is wrapped in shapeless's `Lazy` the induction will not take 121 | advantage of this algorithm. In some cases it may be possible to drop the use of `Lazy`, though not all. Later TLS 122 | releases will provide an interpretation of byname implicit arguments which is equivalent to shapeless's `Lazy` and 123 | which will get along nicely with this induction heuristic. 124 | 125 | More details on the [PR][pr-inductive-implicits]. 126 | 127 | ### Minimal kind-polymorphism ([pull/5538][pr-kind-polymorphism], [@mandubian][mandubian]) 128 | 129 | Enabled by `-Ykind-polymorphism`, it is now possible to write type and method definitions with type parameters of 130 | arbitrary kinds. 131 | 132 | The following is an example of a type class which is indexed by types of arbitrary kinds, 133 | 134 | ```scala 135 | trait Foo[T <: AnyKind] { type Out ; def id(t: Out): Out = t } 136 | 137 | object Foo { 138 | implicit def foo0[T] = new Foo[T] { type Out = T } 139 | implicit def foo1[T[_]] = new Foo[T] { type Out = T[Any] } 140 | implicit def foo2[T[_, _]] = new Foo[T] { type Out = T[Any, Any] } 141 | } 142 | 143 | def foo[T <: AnyKind](implicit f: Foo[T]): f.type = f 144 | 145 | foo[Int].id(23) 146 | foo[List].id(List[Any](1, 2, 3)) 147 | foo[Map].id(Map[Any, Any](1 -> "toto", 2 -> "tata", 3 -> "tutu")) 148 | ``` 149 | 150 | The special type `AnyKind` is used as a bound to indicate that a type variable may be instantiated by a type argument 151 | of any kind. Instances of the type class are then provided for types of kind `*`, kind `* -> *` and kind `* -> * -> *`. 152 | 153 | More examples can be found [here][kind-poly-examples]. 154 | 155 | More details on the [PR][pr-kind-polymorphism]. 156 | 157 | ### Configurable default imports ([pull/5350][pr-default-imports], [@andyscott][andyscott]) 158 | 159 | Enabled by `-Ysysdef` and `-Ypredef`, it is now possible to specify the default imports for a Scala compilation 160 | allowing, for example, an alternative `Predef` to be used. 161 | 162 | By default, scalac imports `java.lang._`, `scala._`, and `scala.Predef._` into the namespace of Scala compilation 163 | units. In Lightbend Scala, we have two flags that adjust the behavior of predefined imports. 164 | 165 | + `-Yno-imports` disables all of these. 166 | + `-Yno-predef` disables `scala.Predef._`. 167 | 168 | There are a few other nuances to the behavior of imports. The most important behavior is that `scala.Predef._` is 169 | unimported/evicted if there are any direct leading imports for anything within `scala.Predef`. For example, an import 170 | of `scala.Predef.DummyImplicit` will cause everything else normally imported by predef to be unimported. 171 | 172 | This feature introduces the notion of "sysdefs" and "predefs" for Scala compilation units. Sysdefs are global imports 173 | that are imported at the top of all Scala compilation units under all circumstances. Predefs are imported after 174 | sysdefs and can be masked by top level imports in the source file (to match the existing behavior of directly 175 | importing from scala.Predef). 176 | 177 | It adds, 178 | 179 | + `-Ysysdef` which controls the global sysdef imports for all Scala compilation units. The default value is set to 180 | `java.lang._; scala._`. 181 | + `-Ypredef` which controls the predef imports for Scala compilation units. The default value is set to 182 | `scala.Predef._`. 183 | 184 | More details on the [PR][pr-default-imports]. 185 | 186 | ### Literal types ([pull/5310][pr-literal-types], [@milesabin][milessabin]) 187 | 188 | Enabled by `-Yliteral-types`, this implements [SIP-23][sip-23]. Literals can now appear in type position, designating 189 | the corresponding singleton type. A `scala.ValueOf[T]` type class and corresponding `scala.Predef.valueOf[T]` operator 190 | has been added yielding the unique value of types with a single inhabitant. Support for `scala.Symbol` literal types 191 | has been added. 192 | 193 | Literal types have many applications in situations where a type can be specified more precisely in terms of a literal 194 | value. The following example defines the type of integers modulo some `M`. 195 | 196 | ```scala 197 | case class Residue[M <: Int](n: Int) extends AnyVal { 198 | def +(rhs: Residue[M])(implicit m: ValueOf[M]): Residue[M] = 199 | Residue((this.n + rhs.n) % valueOf[M]) 200 | } 201 | 202 | val fiveModTen = Residue[10](5) 203 | val nineModTen = Residue[10](9) 204 | 205 | fiveModTen + nineModTen // OK == Residue[10](4) 206 | 207 | val fourModEleven = Residue[11](4) 208 | 209 | //fiveModTen + fourModEleven // compiler error: type mismatch; 210 | // found : Residue[11] 211 | // required: Residue[10] 212 | ``` 213 | 214 | Because the modulus is specified by a literal type it can be checked at compile time and has no runtime storage cost. 215 | Literal types for `String`s and `Symbol`s also greatly simplify type signatures when working with shapeless records. 216 | 217 | More details on the [PR][pr-literal-types]. 218 | 219 | ### Exhaustivity of extractors, guards, and unsealed traits ([pull/5617][pr-exhaustivity], [@sellout][sellout]) 220 | 221 | Enabled by `-Xstrict-patmat-analysis`, the feature provides more accurate reporting of failures of match 222 | exhaustivity for patterns with guards or extractors. Additionally, `-Xlint:strict-unsealed-patmat` will warn on 223 | inexhaustive matches against unsealed traits. 224 | 225 | The following will now warn that the match might not be exhaustive, 226 | 227 | ```scala 228 | def nonExhaustiveIfWeAssumeGuardsFalse(x: Option[Int]): Int = x match { 229 | case Some(n) if n % 2 == 0 => n 230 | case None => 0 231 | } 232 | ``` 233 | 234 | More details on the [PR][pr-exhaustivity]. 235 | 236 | ### Infix type printing ([pull/5589][pr-infix-types], [@allisonhb][allisonhb]) — graduated in LBS 2.12.2 237 | 238 | Two-parameter types with symbolic names now print in infix form by default. A `@showAsInfix` annotation has been added 239 | to enable or disable that behaviour explicitly for specific types. 240 | 241 | This provides much easier to read type signatures in the Scala REPL and elsewhere with libraries such as shapeless 242 | which make heavy use of infix type constructors, 243 | 244 | ```scala 245 | scala> import shapeless._ 246 | import shapeless._ 247 | 248 | scala> case class Foo(i: Int, s: String) 249 | defined class Foo 250 | 251 | scala> val foo = Foo(23, "foo") 252 | foo: Foo = Foo(23,foo) 253 | 254 | scala> Generic[Foo].to(foo) 255 | res0: Int :: String :: shapeless.HNil = 23 :: foo :: HNil 256 | ``` 257 | 258 | More details on the [PR][pr-infix-types]. 259 | 260 | ### Trailing commas ([pull/5245][pr-trailing-commas], [@dwijnand][dwijnand]) — graduated in LBS 2.12.2 261 | 262 | Comma separated lists are now allowed to have a trailing comma. This applies to tuples, argument and parameter groups 263 | and import selectors. 264 | 265 | The features makes adding and removing elements from multiline parameter lists a lot less laborious. For example, the 266 | following is now legal, 267 | 268 | ```scala 269 | trait SimpleExpr1 { 270 | def f: (Int, String) = ( 271 | 23, 272 | "bar", 273 | ) 274 | 275 | // the Tuple1 value case, the trailing comma is ignored so the type is Int and the value 23 276 | def g: Int = ( 277 | 23, 278 | ) 279 | } 280 | 281 | trait TypeArgs { 282 | class C[A, B] 283 | def f: C[ 284 | Int, 285 | String, 286 | ] 287 | } 288 | ``` 289 | 290 | More examples can be found [here][trailing-comma-examples]. 291 | 292 | More details on the [PR][pr-trailing-commas]. 293 | 294 | ## How to use Typelevel Scala 4 with SBT 295 | 296 | Requirements for using Typelevel Scala in your existing projects, 297 | 298 | + You must be using Lightbend Scala 2.11.11, 2.12.4 or 2.13.0-M2. 299 | + You must be using SBT 0.13.15 or later. 300 | + Your build should use `scalaOrganization.value` and `CrossVersion.patch` appropriately. 301 | 302 | You can find many examples linked to from [this issue][build-tweaks-1]. 303 | + (Optional) Your build should scope `scalaVersion` to `ThisBuild`. 304 | 305 | You can find an example in [the shapeless build][build-tweaks-2], 306 | 307 | ``` 308 | inThisBuild(Seq( 309 | organization := "com.chuusai", 310 | scalaVersion := "2.12.4", 311 | crossScalaVersions := Seq("2.10.6", "2.11.11", "2.12.4", "2.13.0-M2") 312 | )) 313 | ``` 314 | 315 | You can now temporarily build with Typelevel Scala by entering, 316 | 317 | ``` 318 | > ; set every scalaOrganization := "org.typelevel" ; ++2.12.4-bin-typelevel-4 319 | ``` 320 | 321 | on the SBT REPL. 322 | 323 | To switch your project permanently to Typelevel Scala 4 update your `build.sbt` as follows, 324 | 325 | ``` 326 | inThisBuild(Seq( 327 | scalaOrganization := "org.typelevel", 328 | scalaVersion := "2.12.4-bin-typelevel-4" 329 | )) 330 | ``` 331 | 332 | Alternatively, if you want to try Typelevel Scala without modifying your `build.sbt` and you have scoped 333 | `scalaVersion` as shown earlier you can instead create a file `local.sbt` at the root of your project with the 334 | following content, 335 | 336 | ``` 337 | inThisBuild(Seq( 338 | scalaOrganization := "org.typelevel", 339 | scalaVersion := "2.11.11-bin-typelevel-4" 340 | )) 341 | ``` 342 | 343 | These settings will override the `ThisBuild` scoped settings in your `build.sbt`. 344 | 345 | Whichever method you choose, your build should now function as before but using the Typelevel Scala toolchain instead 346 | of the Lightbend one. You can verify that the settings have been updated correctly from the SBT prompt using `show`, 347 | 348 | ``` 349 | > show scalaOrganization 350 | [info] org.typelevel 351 | > show scalaVersion 352 | [info] 2.12.4-bin-typelevel-4 353 | ``` 354 | 355 | [build-tweaks-1]: https://github.com/typelevel/scala/issues/135 356 | [build-tweaks-2]: https://github.com/milessabin/shapeless/blob/master/build.sbt#L13-L17 357 | 358 | ## How to use Typelevel Scala 4 with Maven 359 | 360 | If you are using maven with the `scala-maven-plugin`, set the `` to `org.typelevel`, 361 | 362 | ``` 363 | 364 | net.alchim31.maven 365 | scala-maven-plugin 366 | 3.2.1 367 | 368 | org.typelevel 369 | 2.12.4-bin-typelevel-4 370 | 371 | 372 | ``` 373 | 374 | ## Contributors 375 | 376 | Typelevel Scala is only possible because of the contributions made to Lightbend Scala — see the contributors 377 | section of the LBS Scala 2.12.4 and 2.11.11 [release notes][lbs-2.12.4]. 378 | 379 | We are hugely grateful to the following for their work on the enhancements included in Typelevel Scala 4 and look 380 | forward to them being included in future Lightbend Scala releases, 381 | 382 | + Allison H. [@allisonhb][allisonhb] 383 | + Andy Scott [@andyscott][andyscott] 384 | + Dale Wijnand [@dwijnand][dwijnand] 385 | + Greg Pfeil [@sellout][sellout] 386 | + Miles Sabin [@milessabin][milessabin] 387 | + Pascal Voitot [@mandubian][mandubian] 388 | + Paul Phillips [@paulp][paulp] 389 | 390 | We would also like to thank Adriaan Moors, George Leontiev, Jason Zaugg and Vlad Ureche for their contributions to 391 | Typelevel Scala in general and to the PRs merged in this release in particular. 392 | 393 | [allisonhb]: https://github.com/allisonhb 394 | [andyscott]: https://github.com/andyscott 395 | [dwijnand]: https://github.com/dwijnand 396 | [sellout]: https://github.com/sellout 397 | [milessabin]: https://github.com/milessabin 398 | [mandubian]: https://github.com/mandubian 399 | [paulp]: https://github.com/paulp 400 | [pr-infix-types]: https://github.com/scala/scala/pull/5589 401 | [pr-default-imports]: https://github.com/scala/scala/pull/5350 402 | [pr-trailing-commas]: https://github.com/scala/scala/pull/5245 403 | [pr-exhaustivity]: https://github.com/scala/scala/pull/5617 404 | [pr-literal-types]: https://github.com/scala/scala/pull/5310 405 | [pr-inductive-implicits]: https://github.com/scala/scala/pull/5649 406 | [pr-kind-polymorphism]: https://github.com/scala/scala/pull/5538 407 | [pr-pattern-targs]: https://github.com/scala/scala/pull/5774 408 | [merge-policy]: https://github.com/typelevel/scala#relationship-with-lightbend-scala 409 | [tls]: https://github.com/typelevel/scala 410 | [lbs]: https://github.com/scala/scala 411 | [tls-gitter]: https://gitter.im/typelevel/scala 412 | [lbs-gitter]: https://gitter.im/scala/contributors 413 | [typelevel]: http://typelevel.org/ 414 | [lbs-readme]: https://github.com/scala/scala/blob/2.12.x/README.md 415 | [2.12.4-bin-typelevel-4]: https://github.com/typelevel/scala/commits/2.12.4-bin-typelevel-4 416 | [2.11.11-bin-typelevel-4]: https://github.com/typelevel/scala/commits/2.11.11-bin-typelevel-4 417 | [2.13.0-M2-bin-typelevel-4]: https://github.com/typelevel/scala/commits/2.13.0-M2-bin-typelevel-4 418 | [lbs-2.12.4]: https://www.scala-lang.org/news/2.12.4 419 | [sip-23]: http://docs.scala-lang.org/sips/pending/42.type.html 420 | [shapeless]: https://github.com/milessabin/shapeless 421 | [induction-benchmark]: https://github.com/typelevel/scala/blob/2.12.4-bin-typelevel-4/test/induction/inductive-implicits-bench.scala 422 | [kind-poly-examples]: https://github.com/typelevel/scala/blob/2.12.4-bin-typelevel-4/test/files/pos/kind-poly.scala 423 | [trailing-comma-examples]: https://github.com/typelevel/scala/blob/2.12.4-bin-typelevel-4/test/files/pos/trailing-commas.scala 424 | [typeable]: https://github.com/milessabin/shapeless/commit/820f12c678a7c1bb2bfb98c201db207cc7fc81de 425 | -------------------------------------------------------------------------------- /project/build.properties: -------------------------------------------------------------------------------- 1 | sbt.version = 0.13.12 -------------------------------------------------------------------------------- /project/plugins.sbt: -------------------------------------------------------------------------------- 1 | addSbtPlugin("com.fortysevendeg" % "sbt-microsites" % "0.4.0") 2 | -------------------------------------------------------------------------------- /scripts/decrypt-keys.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | openssl aes-256-cbc -K $encrypted_53c898739c54_key -iv $encrypted_53c898739c54_iv -in travis-deploy-key.enc -out travis-deploy-key -d 4 | chmod 600 travis-deploy-key; 5 | cp travis-deploy-key ~/.ssh/id_rsa; 6 | -------------------------------------------------------------------------------- /scripts/publishMicrosite.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -e 3 | 4 | git config --global user.email "bot@typelevel.org" 5 | git config --global user.name "Typelevel Bot" 6 | git config --global push.default simple 7 | 8 | sbt publishMicrosite 9 | -------------------------------------------------------------------------------- /src/main/resources/microsite/css/override.css: -------------------------------------------------------------------------------- 1 | @import url(https://fonts.googleapis.com/css?family=Droid+Serif:400,400i,700,700i); 2 | 3 | h1, h2, h3, h4, h5, h6, .brand { 4 | font-family: 'Droid Serif', serif; 5 | } 6 | 7 | .technologies { 8 | display: none; 9 | } -------------------------------------------------------------------------------- /src/main/resources/microsite/data/menu.yml: -------------------------------------------------------------------------------- 1 | options: 2 | - title: Getting Started 3 | url: docs/index.html 4 | 5 | - title: Basic structure 6 | url: docs/basic_structure.html 7 | 8 | - title: Project folders 9 | url: docs/project_structure.html 10 | 11 | - title: Compiler phases 12 | url: docs/phases.html 13 | 14 | - title: Trees 15 | url: docs/trees.html 16 | 17 | - title: Symbols 18 | url: docs/symbols.html 19 | 20 | - title: Types 21 | url: docs/types.html 22 | 23 | - title: References 24 | url: docs/references.html -------------------------------------------------------------------------------- /src/main/resources/microsite/img/jumbotron_pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/typelevel/scala/0e3bd51d3ee6dc5948f4aa559d9dc87aa89f9556/src/main/resources/microsite/img/jumbotron_pattern.png -------------------------------------------------------------------------------- /src/main/resources/microsite/img/jumbotron_pattern2x.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/typelevel/scala/0e3bd51d3ee6dc5948f4aa559d9dc87aa89f9556/src/main/resources/microsite/img/jumbotron_pattern2x.png -------------------------------------------------------------------------------- /src/main/resources/microsite/img/navbar_brand.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/typelevel/scala/0e3bd51d3ee6dc5948f4aa559d9dc87aa89f9556/src/main/resources/microsite/img/navbar_brand.png -------------------------------------------------------------------------------- /src/main/resources/microsite/img/navbar_brand2x.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/typelevel/scala/0e3bd51d3ee6dc5948f4aa559d9dc87aa89f9556/src/main/resources/microsite/img/navbar_brand2x.png -------------------------------------------------------------------------------- /src/main/resources/microsite/img/poster.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/typelevel/scala/0e3bd51d3ee6dc5948f4aa559d9dc87aa89f9556/src/main/resources/microsite/img/poster.png -------------------------------------------------------------------------------- /src/main/resources/microsite/img/sidebar_brand.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/typelevel/scala/0e3bd51d3ee6dc5948f4aa559d9dc87aa89f9556/src/main/resources/microsite/img/sidebar_brand.png -------------------------------------------------------------------------------- /src/main/resources/microsite/img/sidebar_brand2x.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/typelevel/scala/0e3bd51d3ee6dc5948f4aa559d9dc87aa89f9556/src/main/resources/microsite/img/sidebar_brand2x.png -------------------------------------------------------------------------------- /src/main/tut/docs/basic_structure.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: docs 3 | title: Basic structure of the Compiler 4 | --- 5 | 6 | Understanding the basic structure 7 | 8 | WIP 9 | 10 | Want to contribute? [Edit this file](https://github.com/typelevel/scala/edit/typelevel-readme/src/main/resources/microsite/docs/basic_structure.md) 11 | 12 | 13 | 14 | 15 | -------------------------------------------------------------------------------- /src/main/tut/docs/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: docs 3 | title: Getting Started 4 | --- 5 | 6 | The description part is intended as a guide for programmers seeking to understand the structure, 7 | and operation of the compiler, and its implementation. Some of its aspects are the following ones: 8 | 9 | Some of these contents provide an overview of the compiler code and operation, and the organisation of 10 | the project. 11 | 12 | * [Basic structure of the Scala Compiler](./basic_structure.html) 13 | * [Project folder structure](./project_structure.html) 14 | * [Compiler phases](./phases.html) 15 | 16 | Some contents are specifically dedicated to the key data structures in the compiler that 17 | represents elements of the Scala language. 18 | 19 | * [Trees](./trees.html) 20 | * [Symbols](./symbols.html) 21 | * [Types](./types.html) 22 | 23 | If you want to contribute, you can easily do so via edit links present at the bottom of the pages [like this one](https://github.com/typelevel/scala/edit/typelevel-readme/src/main/resources/microsite/docs/index.md) 24 | -------------------------------------------------------------------------------- /src/main/tut/docs/phases.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: docs 3 | title: Compiler Phases 4 | --- 5 | 6 | The Scala compiler has to do a lot of work to turn your code into jvm bytecode that can be executed. For several reasons, this work is broken into steps which are executed sequentially, the so called *phases* of the compiler. 7 | 8 | ## The Phases 9 | 10 | If you want to see the phases listed, simply run in your terminal: 11 | 12 | ```scala 13 | $ scalac -Xshow-phases 14 | Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 15 | 16 | phase name id description 17 | ---------- -- ----------- 18 | parser 1 parse source into ASTs, perform simple desugaring 19 | namer 2 resolve names, attach symbols to named trees 20 | packageobjects 3 load package objects 21 | typer 4 the meat and potatoes: type the trees 22 | patmat 5 translate match expressions 23 | superaccessors 6 add super accessors in traits and nested classes 24 | extmethods 7 add extension methods for inline classes 25 | pickler 8 serialize symbol tables 26 | refchecks 9 reference/override checking, translate nested objects 27 | uncurry 10 uncurry, translate function values to anonymous classes 28 | tailcalls 11 replace tail calls by jumps 29 | specialize 12 specialized-driven class and method specialization 30 | explicitouter 13 this refs to outer pointers 31 | erasure 14 erase types, add interfaces for traits 32 | posterasure 15 clean up erased inline classes 33 | lazyvals 16 allocate bitmaps, translate lazy vals into lazified defs 34 | lambdalift 17 move nested functions to top level 35 | constructors 18 move field definitions into constructors 36 | flatten 19 eliminate inner classes 37 | mixin 20 mixin composition 38 | cleanup 21 platform-specific cleanups, generate reflective calls 39 | delambdafy 22 remove lambdas 40 | icode 23 generate portable intermediate code 41 | jvm 24 generate JVM bytecode 42 | terminal 25 the last phase during a compilation run 43 | ``` 44 | 45 | As you can see above, at the time of this writing the compiler uses 25 phases that start with a *parser* of the code and end with the *terminal* phase, that ends the compilation. 46 | 47 | Please note that the reality of the compiler is not as clean as this documentation would have you believe. Due to efficiency and other concerns, some phases are intertwined and they should be considered a single phase in itself. In other cases some phases do more than advertised. 48 | 49 | ### Phases in the Compiler 50 | 51 | If you open your compiler codebase and go to class `Global`, line 405, you will see: 52 | 53 | ```scala 54 | // phaseName = "parser" 55 | lazy val syntaxAnalyzer = new { 56 | val global: Global.this.type = Global.this 57 | } with SyntaxAnalyzer { 58 | val runsAfter = List[String]() 59 | val runsRightAfter = None 60 | override val initial = true 61 | } 62 | ``` 63 | 64 | This corresponds to the first phase of the compiler, `parser`. All the phases are defined as `lazy val`, in order, after this entry. 65 | 66 | If you want to learn more about a specific phase you can always go to the class implementing it. In the example above, that would be `SyntaxAnalyzer`. Most of the phases have documentation that explains the function of the phase. 67 | 68 | Some things that may not be obvious from reading the documentation of the phases, but are relevant: 69 | 70 | * `parser`, the very first phase, tackles a lot of syntactic sugar. For example, at the end of this phase *for-comprehensions* will have been transformed into a series of *flatMap*, *map*, and *filter*. 71 | * `namer`, `packageobjects`, and `typer` (phases 2,3, and 4) are effectively a single phase. Although split into 3 elements for implementation reasons, the dependencies between them means you can consider it one. 72 | * After `typer` (phase 4) completes, all the typechecking has been completed. For example, any error due to Type classes missing an implicit implementation will happen at this stage. The remaining 20 phases work with code that type-checks. Guaranteed ;) 73 | * `pickler` (phase 8) generates attributes for class files which are later on used for compilation against binaries. This is what allows you to use a certain jar file as a library without having to bring the source code of the library along. 74 | * `uncurry` (phase 10) turns functions (like `val f: Int => Int`) to anonymous classes. In JVM 8 this benefits from new structures introduced to work with lambdas. 75 | * `lambalift` (phase 17) lifts nested functions outside of methods, a different task that `uncurry` 76 | * `constructors` (phase 18) generates the constructors for the classes. Keep in mind Scala constructors are very different to the ones expected by the jvm (for instance any expression in the body of a class is executed during construction) so there' quite a bit going on in this phase. 77 | 78 | ## Example 79 | 80 | If we talk about phases we want to mention the `-Xprint` flag in `scalac`. This flag allows you to see the differences between phases. 81 | 82 | To test it, create a file with the following code: 83 | 84 | ```scala 85 | class Foo{ 86 | val i = 23 87 | val j = "blah" 88 | val k = i+j 89 | 90 | def wibble = { 91 | for(c <- k) yield c*2 92 | } 93 | } 94 | ``` 95 | 96 | and compile it with: 97 | 98 | ```bash 99 | $ scalac -Xprint:all .scala 100 | ``` 101 | 102 | You will see the compiler outputs the code as it's seen after each phase that modified something. For example the output will show that after the parser phase the output looks like: 103 | 104 | ```scala 105 | [[syntax trees at end of parser]] // sample.scala 106 | package { 107 | class Foo extends scala.AnyRef { 108 | def () = { 109 | super.(); 110 | () 111 | }; 112 | val i = 23; 113 | val j = "blah"; 114 | val k = i.$plus(j); 115 | def wibble = k.map(((c) => c.$times(2))) 116 | } 117 | } 118 | ``` 119 | 120 | You can notice the class is now inside a package `empty` as we didn't declare any package. You can see a method `` that acts like a pseudo-constructor has been added, the `+` operation assigned to `k` has been expanded to a method `$plus`, and the for comprehension of `wibble` has been expanded to a `map` call. 121 | 122 | Quite a lot has changed in just the first phase :) After typing finishes we get the following output: 123 | 124 | ```scala 125 | [[syntax trees at end of namer]] // sample.scala: tree is unchanged since parser 126 | [[syntax trees at end of packageobjects]] // sample.scala: tree is unchanged since parser 127 | [[syntax trees at end of typer]] // sample.scala 128 | package { 129 | class Foo extends scala.AnyRef { 130 | def (): Foo = { 131 | Foo.super.(); 132 | () 133 | }; 134 | private[this] val i: Int = 23; 135 | def i: Int = Foo.this.i; 136 | private[this] val j: String = "blah"; 137 | def j: String = Foo.this.j; 138 | private[this] val k: String = Foo.this.i.+(Foo.this.j); 139 | def k: String = Foo.this.k; 140 | def wibble: scala.collection.immutable.IndexedSeq[Int] = scala.this.Predef.augmentString(Foo.this.k).map[Int, scala.collection.immutable.IndexedSeq[Int]](((c: Char) => c.*(2)))(scala.this.Predef.fallbackStringCanBuildFrom[Int]) 141 | } 142 | } 143 | ``` 144 | 145 | The main difference is that types are assigned. For example our `val i` has type `Int`, as do the other `val` of `def` in the class. We can also see the synthetic methods added to access the values of `i`, `j`, and `k`. 146 | 147 | You can experiment around with your own files to see changes in the output of `scalac`. A warning though, avoid using `extends App` constructs as the compiler treats them in a specific way and that may clutter your output. 148 | 149 | The full output for the example above follows: 150 | 151 | ```scala 152 | scalac -Xprint:all sample.scala 153 | Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 154 | [[syntax trees at end of parser]] // sample.scala 155 | package { 156 | class Foo extends scala.AnyRef { 157 | def () = { 158 | super.(); 159 | () 160 | }; 161 | val i = 23; 162 | val j = "blah"; 163 | val k = i.$plus(j); 164 | def wibble = k.map(((c) => c.$times(2))) 165 | } 166 | } 167 | 168 | [[syntax trees at end of namer]] // sample.scala: tree is unchanged since parser 169 | [[syntax trees at end of packageobjects]] // sample.scala: tree is unchanged since parser 170 | [[syntax trees at end of typer]] // sample.scala 171 | package { 172 | class Foo extends scala.AnyRef { 173 | def (): Foo = { 174 | Foo.super.(); 175 | () 176 | }; 177 | private[this] val i: Int = 23; 178 | def i: Int = Foo.this.i; 179 | private[this] val j: String = "blah"; 180 | def j: String = Foo.this.j; 181 | private[this] val k: String = Foo.this.i.+(Foo.this.j); 182 | def k: String = Foo.this.k; 183 | def wibble: scala.collection.immutable.IndexedSeq[Int] = scala.this.Predef.augmentString(Foo.this.k).map[Int, scala.collection.immutable.IndexedSeq[Int]](((c: Char) => c.*(2)))(scala.this.Predef.fallbackStringCanBuildFrom[Int]) 184 | } 185 | } 186 | 187 | [[syntax trees at end of patmat]] // sample.scala: tree is unchanged since typer 188 | [[syntax trees at end of superaccessors]] // sample.scala: tree is unchanged since typer 189 | [[syntax trees at end of extmethods]] // sample.scala: tree is unchanged since typer 190 | [[syntax trees at end of pickler]] // sample.scala: tree is unchanged since typer 191 | [[syntax trees at end of refchecks]] // sample.scala: tree is unchanged since typer 192 | [[syntax trees at end of uncurry]] // sample.scala 193 | package { 194 | class Foo extends Object { 195 | def (): Foo = { 196 | Foo.super.(); 197 | () 198 | }; 199 | private[this] val i: Int = 23; 200 | def i(): Int = Foo.this.i; 201 | private[this] val j: String = "blah"; 202 | def j(): String = Foo.this.j; 203 | private[this] val k: String = Foo.this.i().+(Foo.this.j()); 204 | def k(): String = Foo.this.k; 205 | def wibble(): scala.collection.immutable.IndexedSeq[Int] = scala.this.Predef.augmentString(Foo.this.k()).map[Int, scala.collection.immutable.IndexedSeq[Int]]({ 206 | @SerialVersionUID(value = 0) final class $anonfun extends scala.runtime.AbstractFunction1[Char,Int] with Serializable { 207 | def (): <$anon: Char => Int> = { 208 | $anonfun.super.(); 209 | () 210 | }; 211 | final def apply(c: Char): Int = c.*(2) 212 | }; 213 | (new <$anon: Char => Int>(): Char => Int) 214 | }, scala.this.Predef.fallbackStringCanBuildFrom[Int]()) 215 | } 216 | } 217 | 218 | [[syntax trees at end of tailcalls]] // sample.scala: tree is unchanged since uncurry 219 | [[syntax trees at end of specialize]] // sample.scala: tree is unchanged since uncurry 220 | [[syntax trees at end of explicitouter]] // sample.scala 221 | package { 222 | class Foo extends Object { 223 | def (): Foo = { 224 | Foo.super.(); 225 | () 226 | }; 227 | private[this] val i: Int = 23; 228 | def i(): Int = Foo.this.i; 229 | private[this] val j: String = "blah"; 230 | def j(): String = Foo.this.j; 231 | private[this] val k: String = Foo.this.i().+(Foo.this.j()); 232 | def k(): String = Foo.this.k; 233 | def wibble(): scala.collection.immutable.IndexedSeq[Int] = scala.this.Predef.augmentString(Foo.this.k()).map[Int, scala.collection.immutable.IndexedSeq[Int]]({ 234 | @SerialVersionUID(value = 0) final class $anonfun extends scala.runtime.AbstractFunction1[Char,Int] with Serializable { 235 | def ($outer: Foo.this.type): <$anon: Char => Int> = { 236 | $anonfun.super.(); 237 | () 238 | }; 239 | final def apply(c: Char): Int = c.*(2); 240 | private[this] val $outer: Foo.this.type = _; 241 | def $outer(): Foo.this.type = $anonfun.this.$outer 242 | }; 243 | (new <$anon: Char => Int>(Foo.this): Char => Int) 244 | }, scala.this.Predef.fallbackStringCanBuildFrom[Int]()) 245 | } 246 | } 247 | 248 | [[syntax trees at end of erasure]] // sample.scala 249 | package { 250 | class Foo extends Object { 251 | def (): Foo = { 252 | Foo.super.(); 253 | () 254 | }; 255 | private[this] val i: Int = 23; 256 | def i(): Int = Foo.this.i; 257 | private[this] val j: String = "blah"; 258 | def j(): String = Foo.this.j; 259 | private[this] val k: String = Foo.this.i().+(Foo.this.j()); 260 | def k(): String = Foo.this.k; 261 | def wibble(): scala.collection.immutable.IndexedSeq = new collection.immutable.StringOps(scala.this.Predef.augmentString(Foo.this.k()).$asInstanceOf[String]()).map({ 262 | @SerialVersionUID(value = 0) final class $anonfun extends scala.runtime.AbstractFunction1 with Serializable { 263 | def ($outer: Foo): <$anon: Function1> = { 264 | $anonfun.super.(); 265 | () 266 | }; 267 | final def apply(c: Char): Int = c.*(2); 268 | private[this] val $outer: Foo = _; 269 | def $outer(): Foo = $anonfun.this.$outer; 270 | final def apply(v1: Object): Object = scala.Int.box($anonfun.this.apply(unbox(v1))) 271 | }; 272 | (new <$anon: Function1>(Foo.this): Function1) 273 | }, scala.this.Predef.fallbackStringCanBuildFrom()).$asInstanceOf[scala.collection.immutable.IndexedSeq]() 274 | } 275 | } 276 | 277 | [[syntax trees at end of posterasure]] // sample.scala 278 | package { 279 | class Foo extends Object { 280 | def (): Foo = { 281 | Foo.super.(); 282 | () 283 | }; 284 | private[this] val i: Int = 23; 285 | def i(): Int = Foo.this.i; 286 | private[this] val j: String = "blah"; 287 | def j(): String = Foo.this.j; 288 | private[this] val k: String = Foo.this.i().+(Foo.this.j()); 289 | def k(): String = Foo.this.k; 290 | def wibble(): scala.collection.immutable.IndexedSeq = new collection.immutable.StringOps(scala.this.Predef.augmentString(Foo.this.k())).map({ 291 | @SerialVersionUID(value = 0) final class $anonfun extends scala.runtime.AbstractFunction1 with Serializable { 292 | def ($outer: Foo): <$anon: Function1> = { 293 | $anonfun.super.(); 294 | () 295 | }; 296 | final def apply(c: Char): Int = c.*(2); 297 | private[this] val $outer: Foo = _; 298 | def $outer(): Foo = $anonfun.this.$outer; 299 | final def apply(v1: Object): Object = scala.Int.box($anonfun.this.apply(unbox(v1))) 300 | }; 301 | (new <$anon: Function1>(Foo.this): Function1) 302 | }, scala.this.Predef.fallbackStringCanBuildFrom()).$asInstanceOf[scala.collection.immutable.IndexedSeq]() 303 | } 304 | } 305 | 306 | [[syntax trees at end of lazyvals]] // sample.scala: tree is unchanged since posterasure 307 | [[syntax trees at end of lambdalift]] // sample.scala 308 | package { 309 | class Foo extends Object { 310 | def (): Foo = { 311 | Foo.super.(); 312 | () 313 | }; 314 | private[this] val i: Int = 23; 315 | def i(): Int = Foo.this.i; 316 | private[this] val j: String = "blah"; 317 | def j(): String = Foo.this.j; 318 | private[this] val k: String = Foo.this.i().+(Foo.this.j()); 319 | def k(): String = Foo.this.k; 320 | def wibble(): scala.collection.immutable.IndexedSeq = new collection.immutable.StringOps(scala.this.Predef.augmentString(Foo.this.k())).map({ 321 | (new <$anon: Function1>(Foo.this): Function1) 322 | }, scala.this.Predef.fallbackStringCanBuildFrom()).$asInstanceOf[scala.collection.immutable.IndexedSeq](); 323 | @SerialVersionUID(value = 0) final class $anonfun$wibble$1 extends scala.runtime.AbstractFunction1 with Serializable { 324 | def ($outer: Foo): <$anon: Function1> = { 325 | $anonfun$wibble$1.super.(); 326 | () 327 | }; 328 | final def apply(c: Char): Int = c.*(2); 329 | private[this] val $outer: Foo = _; 330 | def $outer(): Foo = $anonfun$wibble$1.this.$outer; 331 | final def apply(v1: Object): Object = scala.Int.box($anonfun$wibble$1.this.apply(scala.Char.unbox(v1))) 332 | } 333 | } 334 | } 335 | 336 | [[syntax trees at end of constructors]] // sample.scala 337 | package { 338 | class Foo extends Object { 339 | private[this] val i: Int = _; 340 | def i(): Int = Foo.this.i; 341 | private[this] val j: String = _; 342 | def j(): String = Foo.this.j; 343 | private[this] val k: String = _; 344 | def k(): String = Foo.this.k; 345 | def wibble(): scala.collection.immutable.IndexedSeq = new collection.immutable.StringOps(scala.this.Predef.augmentString(Foo.this.k())).map({ 346 | (new <$anon: Function1>(Foo.this): Function1) 347 | }, scala.this.Predef.fallbackStringCanBuildFrom()).$asInstanceOf[scala.collection.immutable.IndexedSeq](); 348 | @SerialVersionUID(value = 0) final class $anonfun$wibble$1 extends scala.runtime.AbstractFunction1 with Serializable { 349 | final def apply(c: Char): Int = c.*(2); 350 | final def apply(v1: Object): Object = scala.Int.box($anonfun$wibble$1.this.apply(scala.Char.unbox(v1))); 351 | def ($outer: Foo): <$anon: Function1> = { 352 | $anonfun$wibble$1.super.(); 353 | () 354 | } 355 | }; 356 | def (): Foo = { 357 | Foo.super.(); 358 | Foo.this.i = 23; 359 | Foo.this.j = "blah"; 360 | Foo.this.k = Foo.this.i().+(Foo.this.j()); 361 | () 362 | } 363 | } 364 | } 365 | 366 | [[syntax trees at end of flatten]] // sample.scala 367 | package { 368 | class Foo extends Object { 369 | private[this] val i: Int = _; 370 | def i(): Int = Foo.this.i; 371 | private[this] val j: String = _; 372 | def j(): String = Foo.this.j; 373 | private[this] val k: String = _; 374 | def k(): String = Foo.this.k; 375 | def wibble(): scala.collection.immutable.IndexedSeq = new collection.immutable.StringOps(scala.this.Predef.augmentString(Foo.this.k())).map({ 376 | (new <$anon: Function1>(Foo.this): Function1) 377 | }, scala.this.Predef.fallbackStringCanBuildFrom()).$asInstanceOf[scala.collection.immutable.IndexedSeq](); 378 | def (): Foo = { 379 | Foo.super.(); 380 | Foo.this.i = 23; 381 | Foo.this.j = "blah"; 382 | Foo.this.k = Foo.this.i().+(Foo.this.j()); 383 | () 384 | } 385 | }; 386 | @SerialVersionUID(value = 0) final class anonfun$wibble$1 extends scala.runtime.AbstractFunction1 with Serializable { 387 | final def apply(c: Char): Int = c.*(2); 388 | final def apply(v1: Object): Object = scala.Int.box(anonfun$wibble$1.this.apply(scala.Char.unbox(v1))); 389 | def ($outer: Foo): <$anon: Function1> = { 390 | anonfun$wibble$1.super.(); 391 | () 392 | } 393 | } 394 | } 395 | 396 | [[syntax trees at end of mixin]] // sample.scala: tree is unchanged since flatten 397 | [[syntax trees at end of cleanup]] // sample.scala: tree is unchanged since flatten 398 | [[syntax trees at end of delambdafy]] // sample.scala: tree is unchanged since flatten 399 | [[syntax trees at end of icode]] // sample.scala: tree is unchanged since flatten 400 | [[syntax trees at end of jvm]] // sample.scala: tree is unchanged since flatten 401 | ``` 402 | 403 | Want to contribute? [Edit this file](https://github.com/typelevel/scala/edit/typelevel-readme/src/main/resources/microsite/docs/phases.md) -------------------------------------------------------------------------------- /src/main/tut/docs/project_structure.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: docs 3 | title: Project Folder Structure 4 | --- 5 | 6 | Once you [clone](https://github.com/typelevel/scala/) the compiler project (*hint:* ensure you are in a branch with the compiler code, not a documentation branch) you will see several folders and files. 7 | 8 | ## Repository structure 9 | 10 | Your starting point should be the `README.md` file at the root, which describes the project a bit more. This file contains a description of the project structure, which we reproduce below: 11 | 12 | ``` 13 | scala/ 14 | +--build.sbt The main sbt build script 15 | +--build.xml The deprecated Ant build script 16 | +--pull-binary-libs.sh Pulls artifacts from remote repository, used by build 17 | +--lib/ Pre-compiled libraries for the build 18 | +--src/ All sources 19 | +---/compiler Scala Compiler 20 | +---/library Scala Standard Library 21 | +---/library-aux Set of files for bootstrapping and documentation 22 | +---/reflect Scala Reflection 23 | +---/repl REPL source 24 | +---/scaladoc Scaladoc source 25 | +---/scalap Scalap source 26 | +---/eclipse Eclipse project files 27 | +---/ensime Ensime project templates 28 | +---/intellij IntelliJ project templates 29 | +---... other folders like 'manual', etc 30 | +--spec/ The Scala language specification 31 | +--scripts/ Scripts for the CI jobs (including building releases) 32 | +--test/ The Scala test suite 33 | +---/benchmarks Benchmark tests using JMH 34 | +---/files Partest tests 35 | +---/junit JUnit tests 36 | +---... Other folders like 'flaky' for flaky tests, etc 37 | partest Script to launch Partest from command line 38 | +--build/ [Generated] Build output directory 39 | ``` 40 | 41 | 42 | Relevant folders when working with the Scala compiler: 43 | 44 | * **src**: source of the compiler. Also contains several IDE specific folders (ensime, eclipse, intellij), as well as the source code for tools like `scaladoc` and `scalap` 45 | * **test**: scala test suite. You may want to focus on the partest side (/files) as well as `junit` and `benchmarks`, for a start 46 | 47 | Folders of certain interest: 48 | 49 | * **spec**: the Scala specification, as a Jekyll project. You can see it published online at [http://www.scala-lang.org/files/archive/spec/](http://www.scala-lang.org/files/archive/spec/) (select the relevant version to see HTML docs) 50 | * **tools**: set of utility bash scripts, for example `scaladoc-diff` to see changes on Scaladoc 51 | 52 | The following folders and files can be ignored when you start working with the Scala compiler as they are not relevant at this stage: 53 | 54 | * **doc**: contains licenses for the project 55 | * **docs**: contains some TODO tasks and notes. Not updated for a long while, doubtful to be relevant anymore 56 | * **lib**: contains sha1 signatures for some jar files used in the project, for example the `ant-dotnet` jar to provide Scala support on .Net 57 | * **META-INF**: contains Manifest file for the project 58 | * **project**: contains helpers for the Scala build configuration. The project is using a standard `build.sbt` file, located at the root of the project 59 | * **scripts**: used for CI 60 | 61 | 62 | ## Compiler's Build Process 63 | 64 | One of the first tasks you want to do is to build the compiler, as a full compile from scratch may take a while. This will allow you to work with the compiler codebase using incremental compilation, which will reduce the build times substantially. 65 | 66 | Compiling the project has no mystery, as we are working with a standard [SBT project](http://www.scala-sbt.org/). This means you want to open a terminal at the root of the project and run `sbt`: 67 | 68 | ```scala 69 | $ sbt 70 | Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 71 | [info] Loading global plugins from /Users/villegap/.sbt/0.13/plugins 72 | [info] Loading project definition from /Users/villegap/Dropbox/Projectes/typelevel-scala/project/project 73 | [info] Loading project definition from /Users/villegap/Dropbox/Projectes/typelevel-scala/project 74 | [info] Updating {file:/Users/villegap/Dropbox/Projectes/typelevel-scala/project/}typelevel-scala-build... 75 | [info] Resolving org.fusesource.jansi#jansi;1.4 ... 76 | [info] Done updating. 77 | [info] *** Welcome to the sbt build definition for Scala! *** 78 | [info] Check README.md for more information. 79 | > 80 | ``` 81 | 82 | Note the output above corresponds to my local version at the time of this entry, yours may vary accordingly. 83 | 84 | Once in `sbt`, run `compile`. The first time this may take several minutes, depending on your computer specifications. 85 | 86 | ```scala 87 | > compile 88 | [info] Updating {file:/Users/villegap/Dropbox/Projectes/typelevel-scala/}library... 89 | [info] Updating {file:/Users/villegap/Dropbox/Projectes/typelevel-scala/}root... 90 | [info] Updating {file:/Users/villegap/Dropbox/Projectes/typelevel-scala/}bootstrap... 91 | [info] Done updating. 92 | [info] Resolving org.scala-lang#scala-library;2.12.0-M5 ... 93 | 94 | [... several entries more where sbt resolves dependencies ...] 95 | [warn] there were 38 deprecation warnings (since 2.10.0) 96 | [warn] there were 25 deprecation warnings (since 2.11.0) 97 | [warn] there were 45 deprecation warnings (since 2.12.0) 98 | [warn] there were 10 deprecation warnings (since 2.12.0-M2) 99 | [warn] there were 118 deprecation warnings in total; re-run with -deprecation for details 100 | [warn] 5 warnings found 101 | [info] Compiling 157 Scala sources to /Users/villegap/Dropbox/Projectes/typelevel-scala/build/quick/classes/reflect... 102 | 103 | [... more deprecation warnings and compilation of other source files ...] 104 | [info] /Users/villegap/Dropbox/Projectes/typelevel-scala/test/junit/scala/tools/testing/ClearAfterClass.java: /Users/villegap/Dropbox/Projectes/typelevel-scala/test/junit/scala/tools/testing/ClearAfterClass.java uses unchecked or unsafe operations. 105 | [info] /Users/villegap/Dropbox/Projectes/typelevel-scala/test/junit/scala/tools/testing/ClearAfterClass.java: Recompile with -Xlint:unchecked for details. 106 | [warn] there was one deprecation warning (since 2.10.0) 107 | [warn] there were two deprecation warnings (since 2.10.1) 108 | [warn] there were 15 deprecation warnings (since 2.11.0) 109 | [warn] there were three deprecation warnings (since 2.11.8) 110 | [warn] there were 21 deprecation warnings in total; re-run with -deprecation for details 111 | [warn] 5 warnings found 112 | [success] Total time: 263 s, completed 21-Nov-2016 18:51:37 113 | ``` 114 | 115 | Once it finishes, you are ready to start hacking the compiler. For more information on the initial compilation you may want to read [Miles Sabin's post](https://milessabin.com/blog/2016/05/13/scalac-hacking/) on working with the compiler, if you haven't already. 116 | 117 | Want to contribute? [Edit this file](https://github.com/typelevel/scala/edit/typelevel-readme/src/main/resources/microsite/docs/project_structure.md) -------------------------------------------------------------------------------- /src/main/tut/docs/references.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: docs 3 | title: References 4 | --- 5 | 6 | We wrote this documentation from our experience on reading, developing, or debugging, some forked 7 | variants of the Scala compiler. 8 | 9 | We would like to thank here those who have written, or given talks, about the inner workings and 10 | structure of the Scala Compiler and its variants. 11 | 12 | ### Video presentations 13 | 14 | * Chris Birchall, [A Deep Dive into Scalac](https://www.youtube.com/watch?v=2742pWdUm6c). 15 | In Scala World, Penrith (UK), September 2015. This a good description of the compiler itself. 16 | 17 | ### Web logs 18 | 19 | * [Miles Sabin](https://github.com/milessabin), [Hacking on scalac — 0 to PR in an hour](https://milessabin.com/blog/2016/05/13/scalac-hacking/). An excellent introduction to working with the Scala compiler. 20 | 21 | Want to contribute? [Edit this file](https://github.com/typelevel/scala/edit/typelevel-readme/src/main/resources/microsite/docs/references.md) -------------------------------------------------------------------------------- /src/main/tut/docs/symbols.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: docs 3 | title: Symbols 4 | --- 5 | 6 | The official documentation of the compiler has a great section explaining [Symbols](http://docs.scala-lang.org/overviews/reflection/symbols-trees-types.html). 7 | 8 | Want to contribute? [Edit this file](https://github.com/typelevel/scala/edit/typelevel-readme/src/main/resources/microsite/docs/symbols.md) -------------------------------------------------------------------------------- /src/main/tut/docs/trees.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: docs 3 | title: Trees 4 | --- 5 | 6 | This page describes the Scala [AST]() and its implementation within the Scala compiler code. 7 | 8 | The AST is designed to capture the syntactic constructs of the Scala Programming Language, 9 | as described in the [language specification](https://www.scala-lang.org/files/archive/spec/2.12/13-syntax-summary.html). The implementation of the Tree is encoded in [this file](https://github.com/scala/scala/blob/2.13.x/src/reflect/scala/reflect/internal/Trees.scala) 10 | 11 | The official documentation of the compiler has a great section giving more details on [Trees](http://docs.scala-lang.org/overviews/reflection/symbols-trees-types.html)/ 12 | 13 | Want to contribute? [Edit this file](https://github.com/typelevel/scala/edit/typelevel-readme/src/main/resources/microsite/docs/trees.md) -------------------------------------------------------------------------------- /src/main/tut/docs/types.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: docs 3 | title: Types 4 | --- 5 | 6 | Types in scalac 7 | 8 | WIP 9 | 10 | Want to contribute? [Edit this file](https://github.com/typelevel/scala/edit/typelevel-readme/src/main/resources/microsite/docs/types.md) 11 | -------------------------------------------------------------------------------- /test/files/neg/t4225-neg.log: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/typelevel/scala/0e3bd51d3ee6dc5948f4aa559d9dc87aa89f9556/test/files/neg/t4225-neg.log -------------------------------------------------------------------------------- /test/files/pos/t4225-pos.log: -------------------------------------------------------------------------------- 1 | error: assertion failed: mkAttributedQualifier(_1.type, ) 2 | -------------------------------------------------------------------------------- /travis-deploy-key.enc: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/typelevel/scala/0e3bd51d3ee6dc5948f4aa559d9dc87aa89f9556/travis-deploy-key.enc -------------------------------------------------------------------------------- /try-typelevel-scala.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | COURSIER_URL=https://git.io/vgvpD 3 | test -e ~/.coursier/coursier || \ 4 | (mkdir -p ~/.coursier && curl -L -s --output ~/.coursier/coursier $COURSIER_URL && chmod +x ~/.coursier/coursier) 5 | ~/.coursier/coursier launch -q -P \ 6 | com.lihaoyi:ammonite_2.12.4:1.0.3 \ 7 | -E org.scala-lang:scala-library \ 8 | -E org.scala-lang:scala-compiler \ 9 | -E org.scala-lang:scala-reflect \ 10 | org.typelevel:scala-compiler:2.12.4-bin-typelevel-4 \ 11 | org.typelevel:scala-library:2.12.4-bin-typelevel-4 \ 12 | org.typelevel:scala-reflect:2.12.4-bin-typelevel-4 \ 13 | -- < /dev/tty 14 | --------------------------------------------------------------------------------