Dotty Documentation

0.14.0-bin-SNAPSHOT

class DocCompiler
extends Compiler

Custom Compiler with phases for the documentation tool

The idea here is to structure dottydoc around the new infrastructure. As such, dottydoc will itself be a compiler. It will, however, produce a format that can be used by other tools or web-browsers.

Example: 1. Use the existing FrontEnd to typecheck the code being fed to dottydoc, wihtout discarding AnyVal interfaces 2. Create an AST that is serializable 3. Serialize to JS object

[-] Constructors

DocCompiler ( )

[-] Members

[+] private class DocFrontEnd

DocFrontEnd uses the Dotty FrontEnd without discarding the AnyVal interfaces for Boolean, Int, Char, Long, Byte etc.

If -from-tasty is set, then the trees and documentation will be loaded from TASTY. The comments will be cooked after being unpickled.

It currently still throws away Java sources by overriding discardAfterTyper.

[+] override def newRun ( implicit ctx: Context ) : Run
[+] override def phases : List [ List [ Phase ] ]

Meta-ordering constraint:

DenotTransformers that change the signature of their denotation's info must go after erasure. The reason is that denotations are permanently referred to by TermRefs which contain a signature. If the signature of a symbol would change, all refs to it would become outdated - they could not be dereferenced in the new phase.

After erasure, signature changing denot-transformers are OK because erasure will make sure that only term refs with fixed SymDenotations survive beyond it. This is possible because:

  • splitter has run, so every ident or select refers to a unique symbol
  • after erasure, asSeenFrom is the identity, so every reference has a plain SymDenotation, as opposed to a UniqueRefDenotation.