Replace dotr -> scala and dotd -> scalad in the docs

Replace dotc -> scalac in the docs

Author: anatoliykmetyuk

docs/_includes/getting-started.html

@@ -8,9 +8,9 @@ <h1 id="getting-started">Try Dotty</h1>
         <p>If you are a Linux or Windows user, download the <a href="https://github.com/lampepfl/dotty/releases">latest release</a>. Optionally add path of the folder <code>bin/</code> to the system environment variable <code>PATH</code>. </p>
 
         <p>Now you can compile Scala source code:</p>
-        <pre><code>dotc hello.scala</code></pre>
+        <pre><code>scalac hello.scala</code></pre>
 
-        <p>To start the REPL, run: <code>dotr</code>.</p>
+        <p>To start the REPL, run: <code>scala</code>.</p>
 
         <p>Or, you can try Dotty in your browser with <a href="https://scastie.scala-lang.org/?target=dotty">Scastie</a>.</p>
 

docs/docs/contributing/debug-tests.md

@@ -15,13 +15,13 @@ Both are usually pre-installed on macOS and linux distributions.
 First, compile the file `tests/debug/while.scala`:
 
 ```shell
-$ dotc tests/debug/while.scala
+$ scalac tests/debug/while.scala
 ```
 
 Second, run the compiled class with debugging enabled (suppose the main class is `Test`):
 
 ```shell
-$ dotr -d Test
+$ scala -d Test
 ```
 
 Third, start JDB:
@@ -83,13 +83,13 @@ compiler/test/debug/Gen tests/debug/while.scala > robot
 First, compile the file `tests/debug/while.scala`:
 
 ```shell
-$ dotc tests/debug/while.scala
+$ scalac tests/debug/while.scala
 ```
 
 Second, run the compiled class with debugging enabled:
 
 ```shell
-$ dotr -d Test
+$ scala -d Test
 ```
 
 Finally, run the expect script:

docs/docs/contributing/debugging.md

@@ -32,7 +32,7 @@ object Playground {
 }
 ```
 
-Then, you can debug Dotty by compiling this file via `dotc ../issues/Playground.scala` (from the SBT console) and collecting various debug output in process. This section documents techniques you can use to collect the debug info.
+Then, you can debug Dotty by compiling this file via `scalac ../issues/Playground.scala` (from the SBT console) and collecting various debug output in process. This section documents techniques you can use to collect the debug info.
 
 [This](https://github.com/lampepfl/dotty/blob/10526a7d0aa8910729b6036ee51942e05b71abf6/compiler/src/dotty/tools/dotc/typer/Typer.scala#L2231) is the entry point to the Typer. The job of the Typer is to take an untyped tree, compute its type and turn it into a typed tree by attaching the type information to that tree. We will use this entry point to practice debugging techniques. E.g.:
 
@@ -46,7 +46,7 @@ Then, you can debug Dotty by compiling this file via `dotc ../issues/Playground.
 Then:
 
 ```shell
-dotc ../issues/Playground.scala
+scalac ../issues/Playground.scala
 ```
 
 The techniques discussed below can be tried out in place of `println("Hello Debug")` in that location. They are of course applicable throughout the codebase.
@@ -70,9 +70,9 @@ if (tree.show == """println("Hello World")""")
 
 The intention above is to output an extended debug info on a tree that matches a particular human-readable representation. However, because of the color characters, the comparison will fail.
 
-To disable color output from `show`, run `dotc` as follows:
+To disable color output from `show`, run `scalac` as follows:
 
-`dotc -color:never ../issues/Playground.scala`
+`scalac -color:never ../issues/Playground.scala`
 
 ## Reporting as a non-intrusive println
 Consider you want to debug the `tree` that goes into `assertPositioned(tree)` in the `typed` method. You can do:
@@ -94,19 +94,19 @@ assertPositioned(tree.reporting(s"Tree is: $result"))
 To print out the trees you are compiling after the FrontEnd (scanner, parser, namer, typer) phases:
 
 ```shell
-dotc -Xprint:typer ../issues/Playground.scala
+scalac -Xprint:typer ../issues/Playground.scala
 ```
 
 To print out the trees after Frontend and CollectSuperCalls phases:
 
 ```shell
-dotc -Xprint:typer,collectSuperCalls ../issues/Playground.scala
+scalac -Xprint:typer,collectSuperCalls ../issues/Playground.scala
 ```
 
 To print out the trees after all phases:
 
 ```shell
-dotc -Xprint:all ../issues/Playground.scala
+scalac -Xprint:all ../issues/Playground.scala
 ```
 
 To find out the list of all the phases and their names, check out [this](https://github.com/lampepfl/dotty/blob/10526a7d0aa8910729b6036ee51942e05b71abf6/compiler/src/dotty/tools/dotc/Compiler.scala#L34) line in `Compiler.scala`. Each `Phase` object has `phaseName` defined on it, this is the phase name.
@@ -119,7 +119,7 @@ object Foo
 object Foo
 ```
 
-Clearly we cannot define an object `Foo` twice. Now compile it as follows: `dotc -Ydebug-error ../issues/Playground.scala` (use whatever path you saved it under). The result will be as follows:
+Clearly we cannot define an object `Foo` twice. Now compile it as follows: `scalac -Ydebug-error ../issues/Playground.scala` (use whatever path you saved it under). The result will be as follows:
 
 ```scala
 -- Error: ../issues/Playground.scala:2:0 ---------------------------------------
@@ -173,7 +173,7 @@ val YprintPos: Setting[Boolean] = BooleanSetting("-Yprint-pos", "show tree posit
 And is to be used as:
 
 ```scala
-dotc -Yprint-pos  ../issues/Playground.scala
+scalac -Yprint-pos  ../issues/Playground.scala
 ```
 
 If used, all the trees output with `show` or via `-Xprint:typer` will also have positions attached to them, e.g.:
@@ -204,7 +204,7 @@ package <empty>@<Playground.scala:1> {
 Every [Positioned](https://github.com/lampepfl/dotty/blob/10526a7d0aa8910729b6036ee51942e05b71abf6/compiler/src/dotty/tools/dotc/ast/Positioned.scala) (a parent class of `Tree`) object has a `uniqueId` field. It is an integer that is unique for that tree and doesn't change from compile run to compile run. You can output these IDs from any printer (such as the ones used by `.show` and `-Xprint`) via `-Yshow-tree-ids` flag, e.g.:
 
 ```shell
-dotc -Xprint:typer -Yshow-tree-ids  ../issues/Playground.scala
+scalac -Xprint:typer -Yshow-tree-ids  ../issues/Playground.scala
 ```
 
 Gives:
@@ -229,7 +229,7 @@ package <empty>#1047 {
 You can then use these IDs to locate the creation site of a given tree using that ID via `-Ydebug-tree-with-id`, e.g.:
 
 ```shell
-dotc -Ydebug-tree-with-id 1049 ../issues/Playground.scala
+scalac -Ydebug-tree-with-id 1049 ../issues/Playground.scala
 ```
 
 When the tree with the correspond id is allocated, the following prompt will appear:
@@ -363,4 +363,4 @@ trace.force(i"typing $tree", typr, show = true) { // ...
 ```
 
 ### Reporter
-Defined in [Reporter.scala](https://github.com/lampepfl/dotty/blob/10526a7d0aa8910729b6036ee51942e05b71abf6/compiler/src/dotty/tools/dotc/reporting/Reporter.scala). Enables calls such as `report.log`. To enable, run dotc with `-Ylog:typer` option.
+Defined in [Reporter.scala](https://github.com/lampepfl/dotty/blob/10526a7d0aa8910729b6036ee51942e05b71abf6/compiler/src/dotty/tools/dotc/reporting/Reporter.scala). Enables calls such as `report.log`. To enable, run scalac with `-Ylog:typer` option.

docs/docs/contributing/getting-started.md

@@ -25,8 +25,8 @@ all be done from within sbt:
 
 ```bash
 $ sbt
-> dotc tests/pos/HelloWorld.scala
-> dotr HelloWorld
+> scalac tests/pos/HelloWorld.scala
+> scala HelloWorld
 hello world
 ```
 
@@ -41,10 +41,10 @@ and you will be able to run the corresponding commands directly from your consol
 
 ```shell
 # Compile code using Dotty
-$ dotc tests/pos/HelloWorld.scala
+$ scalac tests/pos/HelloWorld.scala
 
 # Run it with the proper classpath
-$ dotr HelloWorld
+$ scala HelloWorld
 ```
 
 
@@ -62,7 +62,7 @@ scala>
 or via bash:
 
 ```bash
-$ dotr
+$ scala
 ```
 
 

docs/docs/contributing/testing.md

@@ -9,9 +9,9 @@ Running all tests in Dotty is as simple as:
 $ sbt test
 ```
 
-Specifically, `sbt test` runs all tests that do _not_ require a bootstrapped 
-compiler. In practice, this means that it runs all compilation tests meeting 
-this criterion, as well as all non-compiler tests. 
+Specifically, `sbt test` runs all tests that do _not_ require a bootstrapped
+compiler. In practice, this means that it runs all compilation tests meeting
+this criterion, as well as all non-compiler tests.
 
 The entire suite of tests can be run using the bootstrapped compiler as follows:
 
@@ -87,7 +87,7 @@ Test output dumped in: tests/playground/neg/Sample.check.out
 To create a checkfile for a test, you can do one of the following:
 
 - Create a dummy checkfile with a random content, run the test, and, when it fails, use the `mv` command reported by the test to replace the dummy checkfile with the actual output.
-- Manually compile the file you are testing with `dotc` and copy-paste whatever console output the compiler produces to the checkfile.
+- Manually compile the file you are testing with `scalac` and copy-paste whatever console output the compiler produces to the checkfile.
 
 ## Integration tests
 These tests are Scala source files expected to compile with Dotty (pos tests),

docs/docs/contributing/workflow.md

@@ -6,19 +6,19 @@ title: Workflow
 Check [Getting Started](getting-started.md) for instructions on how to obtain the source code of dotty.
 This document details common workflow patterns when working with Dotty.
 
-## Compiling files with dotc ##
+## Compiling files with scalac ##
 
 As we have seen you can compile a test file either from sbt:
 
 ```bash
 $ sbt
-> dotc <OPTIONS> <FILE>
+> scalac <OPTIONS> <FILE>
 ```
 
 or from terminal:
 
 ```bash
-$ dotc <OPTIONS> <FILE>
+$ scalac <OPTIONS> <FILE>
 ```
 
 Here are some useful debugging `<OPTIONS>`:
@@ -60,7 +60,7 @@ u: dotty.tools.dotc.core.Types.Type = TypeBounds(TypeRef(ThisType(TypeRef(NoPref
 ```
 
 ## Pretty-printing ##
-Many objects in the dotc compiler implement a `Showable` trait (e.g. `Tree`,
+Many objects in the scalac compiler implement a `Showable` trait (e.g. `Tree`,
 `Symbol`, `Type`). These objects may be prettyprinted using the `.show`
 method
 
@@ -70,8 +70,8 @@ The basics of working with Dotty codebase are documented [here](https://dotty.ep
 
 |                        Command                       |                                                          Description                                                          |
 |------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|
-| `dotc ../issues/Playground.scala`                    | Compile the given file – path relative to the Dotty directory. Output the compiled class files to the Dotty directory itself. |
-| `dotr Playground`                                    | Run the compiled class `Playground`. Dotty directory is on classpath by default.                                              |
+| `scalac ../issues/Playground.scala`                  | Compile the given file – path relative to the Dotty directory. Output the compiled class files to the Dotty directory itself. |
+| `scala Playground`                                   | Run the compiled class `Playground`. Dotty directory is on classpath by default.                                              |
 | `repl`                                               | Start REPL                                                                                                                    |
 | `testOnly dotty.tools.dotc.CompilationTests -- *pos` | Run test (method) `pos` from `CompilationTests` suite.                                                                        |
 | `testCompilation sample`                             | In all test suites, run test files containing the word `sample` in their title.                                               |

docs/docs/internals/core-data-structures.md

@@ -19,7 +19,7 @@ by tne
 A symbol refers to a definition in a source program. Traditionally,
  compilers store context-dependent data in a _symbol table_. The
  symbol then is the central reference to address context-dependent
- data. But for `dotc`'s requirements it turns out that symbols are
+ data. But for `scalac`'s requirements it turns out that symbols are
  both too little and too much for this task.
 
 Too little: The attributes of a symbol depend on the phase. Examples:
@@ -32,23 +32,23 @@ a trait). So a functional compiler, a `Symbol` by itself met mean
 much. Instead we are more interested in the attributes of a symbol at
 a given phase.
 
-`dotc` has a concept for "attributes of a symbol at
+`scalac` has a concept for "attributes of a symbol at
 
 Too much: If a symbol is used to refer to a definition in another
 compilation unit, we get problems for incremental recompilation. The
 unit containing the symbol might be changed and recompiled, which
 might mean that the definition referred to by the symbol is deleted or
 changed. This leads to the problem of stale symbols that refer to
-definitions that no longer exist in this form. `scalac` tried to
+definitions that no longer exist in this form. Scala 2 compiler tried to
 address this problem by _rebinding_ symbols appearing in certain cross
 module references, but it turned out to be too difficult to do this
-reliably for all kinds of references. `dotc` attacks the problem at
+reliably for all kinds of references. Scala 3 compiler attacks the problem at
 the root instead. The fundamental problem is that symbols are too
 specific to serve as a cross-module reference in a system with
 incremental compilation. They refer to a particular definition, but
 that definition may not persist unchanged after an edit.
 
-`dotc` uses instead a different approach: A cross module reference is
+`scalac` uses instead a different approach: A cross module reference is
 always type, either a `TermRef` or ` TypeRef`. A reference type contains
 a prefix type and a name. The definition the type refers to is established
 dynamically based on these fields.

docs/docs/internals/dotc-scalac.md

@@ -44,14 +44,14 @@ only be applied if an implicit `Context` is in scope.
 
 ### Symbol ###
 * `Symbol` instances have a `SymDenotation`
-* Most symbol properties in scalac are now in the denotation (in dotc)
+* Most symbol properties in the Scala 2 compiler are now in the denotation (in the Scala 3 compiler).
 
 Most of the `isFooBar` properties in scalac don't exist anymore in dotc. Use
 flag tests instead, for example:
 
 ```scala
-if (sym.isPackageClass)         // scalac
-if (sym is Flags.PackageClass)  // dotc (*)
+if (sym.isPackageClass)         // Scala 2
+if (sym is Flags.PackageClass)  // Scala 3 (*)
 ```
 
 `(*)` Symbols are implicitly converted to their denotation, see above. Each

docs/docs/internals/overall-structure.md

@@ -20,7 +20,7 @@ classes, [Compiler] and [Run].
 
 Package Structure
 -----------------
-Most functionality of `dotc` is implemented in subpackages of `dotc`. Here's a
+Most functionality of `scalac` is implemented in subpackages of `dotc`. Here's a
 list of sub-packages and their focus.
 
 ```
@@ -44,10 +44,10 @@ list of sub-packages and their focus.
 
 Contexts
 --------
-`dotc` has almost no global state (the only significant bit of global state is
+`scalac` has almost no global state (the only significant bit of global state is
 the name table, which is used to hash strings into unique names). Instead, all
 essential bits of information that can vary over a compiler run are collected
-in a [Context]. Most methods in `dotc` take a `Context` value as an implicit
+in a [Context]. Most methods in `scalac` take a `Context` value as an implicit
 parameter.
 
 Contexts give a convenient way to customize values in some part of the
@@ -88,7 +88,7 @@ a problem.
 
 Compiler Phases
 ---------------
-Seen from a temporal perspective, the `dotc` compiler consists of a list of
+Seen from a temporal perspective, the `scalac` compiler consists of a list of
 phases. The current list of phases is specified in class [Compiler] as follows:
 
 ```scala

docs/docs/internals/periods.md

@@ -3,14 +3,14 @@ layout: doc-page
 title: "Dotc's concept of time"
 ---
 
-Conceptually, the `dotc` compiler's job is to maintain views of various
+Conceptually, the `scalac` compiler's job is to maintain views of various
 artifacts associated with source code at all points in time.  But what is
-*time* for `dotc`? In fact, it is a combination of compiler runs and compiler
+*time* for `scalac`? In fact, it is a combination of compiler runs and compiler
 phases.
 
 The *hours* of the compiler's clocks are measured in compiler [runs]. Every run
 creates a new hour, which follows all the compiler runs (hours) that happened
-before. `dotc` is designed to be used as an incremental compiler that can
+before. `scalac` is designed to be used as an incremental compiler that can
 support incremental builds, as well as interactions in an IDE and a REPL. This
 means that new runs can occur quite frequently.  At the extreme, every
 keystroke in an editor or REPL can potentially launch a new compiler run, so
@@ -32,7 +32,7 @@ lower-level JVM view. There are different ways to deal with this. Many
 compilers change the type of a symbol destructively according to the "current
 phase". Another, more functional approach might be to have different symbols
 representing the same definition at different phases, which each symbol
-carrying a different immutable type. `dotc` employs yet another scheme, which
+carrying a different immutable type. `scalac` employs yet another scheme, which
 is inspired by functional reactive programming (FRP): Symbols carry not a
 single type, but a function from compiler phase to type. So the type of a
 symbol is a time-indexed function, where time ranges over compiler phases.