diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/docs/contributing/workflow.md | 4 | ||||
| -rw-r--r-- | docs/docs/internals/backend.md | 28 |
2 files changed, 16 insertions, 16 deletions
diff --git a/docs/docs/contributing/workflow.md b/docs/docs/contributing/workflow.md index 48f71053e..fb8da0da3 100644 --- a/docs/docs/contributing/workflow.md +++ b/docs/docs/contributing/workflow.md @@ -33,7 +33,7 @@ Here are some useful debugging `<OPTIONS>`: * `-Xprint:PHASE1,PHASE2,...` or `-Xprint:all`: prints the `AST` after each specified phase. Phase names can be found by searching - `src/dotty/tools/dotc/transform/` for `phaseName`. + `compiler/src/dotty/tools/dotc/transform/` for `phaseName`. * `-Ylog:PHASE1,PHASE2,...` or `-Ylog:all`: enables `ctx.log("")` logging for the specified phase. * `-Ycheck:all` verifies the consistency of `AST` nodes between phases, in @@ -42,7 +42,7 @@ Here are some useful debugging `<OPTIONS>`: `-Ycheck:tailrec,resolveSuper,mixin,restoreScopes,labelDef`. Additional logging information can be obtained by changes some `noPrinter` to -`new Printer` in `src/dotty/tools/dotc/config/Printers.scala`. This enables the +`new Printer` in `compiler/src/dotty/tools/dotc/config/Printers.scala`. This enables the `subtyping.println("")` and `ctx.traceIndented("", subtyping)` style logging. ## Running tests ## diff --git a/docs/docs/internals/backend.md b/docs/docs/internals/backend.md index f10cf1e82..47974b5ff 100644 --- a/docs/docs/internals/backend.md +++ b/docs/docs/internals/backend.md @@ -4,7 +4,7 @@ title: "Backend Internals" --- The code for the backend is split up by functionality and assembled in the -objet `GenBCode`. +object `GenBCode`. ```none object GenBCode --- [defines] --> PlainClassBuilder GenBCode also defines class BCodePhase, the compiler phase @@ -61,29 +61,29 @@ ready for serialization to disk. Currently the queue subsystem is all sequential, but as can be seen in http://magarciaepfl.github.io/scala/ the above design enables overlapping (a.1) -building of ClassNodes, (a.2) intra-method optimizations, and (a.3) +building of `ClassNodes`, (a.2) intra-method optimizations, and (a.3) serialization to disk. -This subsystem is described in detail in GenBCode.scala +This subsystem is described in detail in `GenBCode.scala` #### (b) Bytecode-level types, BType #### The previous bytecode emitter goes to great lengths to reason about bytecode-level types in terms of Symbols. -GenBCode uses BType as a more direct representation. A BType is immutable, and +`GenBCode` uses `BType` as a more direct representation. A `BType` is immutable, and a value class (once the rest of GenBCode is merged from http://magarciaepfl.github.io/scala/ ). Whether value class or not, its API is the same. That API doesn't reach into -the type checker. Instead, each method on a BType answers a question that can -be answered based on the BType itself. Sounds too simple to be good? It's a +the type checker. Instead, each method on a `BType` answers a question that can +be answered based on the `BType` itself. Sounds too simple to be good? It's a good building block, that's what it is. -The internal representation of a BType is based on what the JVM uses: internal -names (eg Ljava/lang/String; ) and method descriptors; as defined in the JVM -spec (that's why they aren't documented in GenBCode, just read the spec). +The internal representation of a `BType` is based on what the JVM uses: internal +names (e.g. `Ljava/lang/String;` ) and method descriptors; as defined in the JVM +spec (that's why they aren't documented in `GenBCode`, just read the [JVM 8 spec](https://docs.oracle.com/javase/specs/jvms/se8/html/)). -All things BType can be found in BCodeGlue.scala +All things `BType` can be found in `BCodeGlue.scala` #### (c) Utilities offering a more "high-level" API to bytecode emission #### Bytecode can be emitted one opcode at a time, but there are recurring patterns @@ -93,7 +93,7 @@ For example, when emitting a load-constant, a dedicated instruction exists for emitting load-zero. Similarly, emitting a switch can be done according to one of two strategies. -All these utilities are encapsulated in file BCodeIdiomatic.scala. They know +All these utilities are encapsulated in file `BCodeIdiomatic.scala`. They know nothing about the type checker (because, just between us, they don't need to). #### (d) Mapping between type-checker types and BTypes #### @@ -109,10 +109,10 @@ To understand how it's built, see: final def exemplar(csym0: Symbol): Tracked = { ... } ``` -Details in BCodeTypes.scala +Details in `BCodeTypes.scala` #### (e) More "high-level" utilities for bytecode emission #### -In the spirit of BCodeIdiomatic, utilities are added in BCodeHelpers for +In the spirit of `BCodeIdiomatic`, utilities are added in `BCodeHelpers` for emitting: - bean info class @@ -122,4 +122,4 @@ emitting: #### (f) Building an ASM ClassNode given an AST TypeDef #### -It's done by PlainClassBuilder +It's done by `PlainClassBuilder`(see `GenBCode.scala`). |