Type Members

1.  trait Action extends AnyRef

   An Action is very miminal representation of a CodeAction in the LSP protocol.

   An Action is very miminal representation of a CodeAction in the LSP protocol.

   However it only focuses on the actual title, description, and edit, leaving it up to the language server to communicate with the client and put together a proper codeAction in accordance to client capabilities.

   See also

   `CodeAction`

2.  trait AnalysisCallback extends AnyRef
3.  trait AnalysisCallback2 extends AnalysisCallback

   Extension to AnalsysisCallback.

   Extension to AnalsysisCallback. This is a compatibility layer created for Scala 3.x compilers. Even though compiler-interface is NOT intended to be a public API, Scala 3 compiler publishes their own compiler bridge against Zinc de jour. By having this interface, they can test if callback supports AnalysisCallback2.

4.  trait AnalysisCallback3 extends AnalysisCallback2

   Extension to AnalysisCallback2.

   Extension to AnalysisCallback2. Similar to AnalysisCallback2, it serves as compatibility layer for Scala compilers.

5.  final class ArtifactInfo extends AnyRef

   Define constants of Scala compiler useful for artifact resolution.

6.  class BasicVirtualFileRef extends VirtualFileRef
7.  abstract class CompileCancelled extends RuntimeException

   Represent the cancellation of a compilation run.

   Represent the cancellation of a compilation run. This failure extends RuntimeException that you can catch at the use-site.

8.  abstract class CompileFailed extends RuntimeException

   Represent a failure occurred during compilation of Java or Scala sources.

   Represent a failure occurred during compilation of Java or Scala sources. This failure extends RuntimeException that you can catch at the use-site.

9.  abstract class CompileFailed2 extends CompileFailed
10.  trait DiagnosticCode extends AnyRef

    A DiagnosticCode is a unique identifier that the compiler can associate with a diagnostic.

    A DiagnosticCode is a unique identifier that the compiler can associate with a diagnostic. This is useful for tools to be able to quickly identify what diagnostic is being reported without having to rely on parsing the actual diagnostic message, which might not be stable.

11.  trait DiagnosticRelatedInformation extends AnyRef

    Related information for a given diagnostic.

    Related information for a given diagnostic. At times this can be another place in your code contributing to the diagnostic or just relevant code relating to the diagnostic.

12.  trait FileConverter extends AnyRef
13.  trait InteractiveConsoleFactory extends AnyRef

    Interface for running console interactively.

    Interface for running console interactively. An implementation is loaded using java.util.ServiceLoader.

14.  trait InteractiveConsoleInterface extends Closeable
15.  trait InteractiveConsoleResponse extends AnyRef

    Public interface for repl responses.

16.  sealed abstract final class InteractiveConsoleResult extends Enum[InteractiveConsoleResult]
17.  trait Logger extends AnyRef
18.  trait PathBasedFile extends VirtualFile
19.  trait Position extends AnyRef
20.  trait Problem extends AnyRef
21.  trait Reporter extends AnyRef

    Define an interface for a reporter of the compiler.

    Define an interface for a reporter of the compiler.

    The reporter exposes compilation errors coming from either Scala or Java compilers. This includes messages with any level of severity: from error, to warnings and infos.

22.  sealed abstract final class Severity extends Enum[Severity]
23.  trait T2[A1, A2] extends AnyRef

    Used to pass a pair of values.

24.  trait TextEdit extends AnyRef

    A representation of the TextEdit found in the LSP protocol.

    A representation of the TextEdit found in the LSP protocol.

    NOTE: That instead of a Range we use the internal xsbti.Position.

    See also

    <a href="https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textEdit">TextEdit

25.  sealed abstract final class UseScope extends Enum[UseScope]

    Defines the scope in which a name hash was captured.

    Defines the scope in which a name hash was captured.

    The incremental compiler uses UseScope to determine some Scala semantics assumed in the presence of a name in a concrete position. For instance, PatMatTarget is used for names that appear as the target types of a pattern match.

    The order of declaration of these is crucial. Don't change it. Don't add more than 6 scopes. Otherwise, change Mapper implementation.

26.  trait VirtualDirectory extends VirtualFileRef
27.  trait VirtualFile extends VirtualFileRef

    VirtualFile is an abstraction for file-like objects.

    VirtualFile is an abstraction for file-like objects. Unlike java.io.File or java.nio.file.Path that are tied to filesystem-related capabilities, VirtualFile is designed to be a less-capable object with identity, content reading, and content hashing. See also VirtualFileRef

    One of the goals of this virtual file (as opposed to a concrete file) is to abstract from the machine and user specifics. Previous Zinc's Analysis metadata files stored file paths using java.io.File. This impeded them from being shared across machines without pre- and post-processing them appropriately.

    To create a VirtualFile you may use a FileConverter, such as MappedFileConverter. MappedFileConverter internally stores the root paths to the working directory, Coursier's cache, etc..., and it will create a VirtualFile with an id that looks like ${BASE}/src/main/example/A.scala.

    A VirtualFile can also be created with plain Strings to represent the content, without any "real" files.

    OK, but how does the compiler compile these?

    See IncrementalCompiler.java. At the top layer of Zinc, we are passing in the source files as a sequence of VirtualFiles. The files then gets wrapped by a datatype called AbstractZincFile, which extends scala.reflect.io.AbstractFile, which the compiler is able to compile.

28.  trait VirtualFileRef extends AnyRef

    VirtualFileRef represents a reference to a file-like object.

    VirtualFileRef represents a reference to a file-like object. Unlike java.io.File or java.nio.file.Path that are tied to filesystem-related capabilities, VirtualFileRef is designed to be a less-capable pointer to an object whose main feature is having a path-like identity. The equality is expected to be implemented using the equality of the id() alone. See BasicVirtualFileRef.

    VirtualFile, a subtype of VirtualFileRef supports minimally viable file-like opration needed for compilation. To illustrate the difference between the two, consider the following flow of operation.

    Flow of operation

    Suppose that there are two people Alice and Bob who are working on the same repo. On Alice's machine, the build tool would construct an instance of FileConverter used for the entire build. The reference implementation is sbt.internal.inc.MappedFileConverter. The build tool would pass the usual suspect of absolute paths to this MappedFileConverter such as the base directory of the working directory, Coursier cache directory, etc. Given the sequence of Scala and Java source files, MappedFileConverter will create a sequence of MappedVirtualFile whose id would look like ${BASE}/src/main/example/A.scala.

    When Alice runs the compilation, Analysis file will store the VirtualFileRef represented by its id. This extends not only to the source files, but also to *.class products and library JAR files. See MRelationsNameHashing.

    Suppose then we are able to package the Analysis together with the *.class files in a JAR file, Bob on a different machine can extract it, and have the same Analysis file. The only difference would be that on his machine the build tool would have created a slightly different FileConverter with different base paths. Because ${BASE}/src/main/example/A.scala would still be called the same, hopefully he can resume incremental compilation.

    Difference between VirtualFileRef and VirtualFile

    VirtualFileRef on its own can only have identity information to be compared against another. At the most basic level this could be implemented as BasicVirtualFileRef that has no ability of reading the content. On the other hand, VirtualFile is internally able to thaw itself back to the "real" file with the help of the FileConverter, and thus it might even be aware of the absolute paths.

    So when we look at the two types VirtualFileRef and VirtualFile, VirtualFileRef could represent a "path" for either the local machine or someone else's machine; on the other hand, VirtualFile would represent something more concrete, like a local file or an in-memory file.

    ok, so how would the compiler compile this?

    See IncrementalCompile.scala. At the top layer of Zinc, we are passing in the source files as a sequence of VirtualFiles. The files then gets wrapped by a datatype called AbstractZincFile, which extends scala.reflect.io.AbstractFile, which the compiler is able to compile.

29.  trait VirtualFileWrite extends VirtualFile
30.  trait WorkspaceEdit extends AnyRef

    A minimal representatin of the WorkspaceEdit found in the LSP protocol.

    A minimal representatin of the WorkspaceEdit found in the LSP protocol.

    However it only supports the minimal changes to ensure the fixes will work with all clients.

    NOTE: In the future this may be expanded to handle resource operations via documentChanges.

    See also

    `WorkspaceEdit`