xsbti
package xsbti
Type Members
-
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
- trait AnalysisCallback extends AnyRef
-
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. -
final
class
ArtifactInfo extends AnyRef
Define constants of Scala compiler useful for artifact resolution.
- class BasicVirtualFileRef extends VirtualFileRef
-
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. -
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. -
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.
-
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.
- trait FileConverter extends AnyRef
-
trait
InteractiveConsoleFactory extends AnyRef
Interface for running console interactively.
Interface for running console interactively. An implementation is loaded using java.util.ServiceLoader.
- trait InteractiveConsoleInterface extends Closeable
-
trait
InteractiveConsoleResponse extends AnyRef
Public interface for repl responses.
- sealed abstract final class InteractiveConsoleResult extends Enum[InteractiveConsoleResult]
- trait Logger extends AnyRef
- trait PathBasedFile extends VirtualFile
- trait Position extends AnyRef
- trait Problem extends AnyRef
-
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.
- sealed abstract final class Severity extends Enum[Severity]
-
trait
T2[A1, A2] extends AnyRef
Used to pass a pair of values.
-
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
-
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. - trait VirtualDirectory extends VirtualFileRef
-
trait
VirtualFile extends VirtualFileRef
VirtualFile
is an abstraction for file-like objects.VirtualFile
is an abstraction for file-like objects. Unlikejava.io.File
orjava.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 alsoVirtualFileRef
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 usingjava.io.File
. This impeded them from being shared across machines without pre- and post-processing them appropriately.To create a
VirtualFile
you may use aFileConverter
, such asMappedFileConverter
.MappedFileConverter
internally stores the root paths to the working directory, Coursier's cache, etc..., and it will create aVirtualFile
with anid
that looks like${BASE}/src/main/example/A.scala
.A
VirtualFile
can also be created with plainString
s 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 ofVirtualFile
s. The files then gets wrapped by a datatype calledAbstractZincFile
, which extendsscala.reflect.io.AbstractFile
, which the compiler is able to compile. -
trait
VirtualFileRef extends AnyRef
VirtualFileRef
represents a reference to a file-like object.VirtualFileRef
represents a reference to a file-like object. Unlikejava.io.File
orjava.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 theid()
alone. SeeBasicVirtualFileRef
.VirtualFile
, a subtype ofVirtualFileRef
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 issbt.internal.inc.MappedFileConverter
. The build tool would pass the usual suspect of absolute paths to thisMappedFileConverter
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 ofMappedVirtualFile
whoseid
would look like${BASE}/src/main/example/A.scala
.When Alice runs the compilation,
Analysis
file will store theVirtualFileRef
represented by itsid
. This extends not only to the source files, but also to*.class
products and library JAR files. SeeMRelationsNameHashing
.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 sameAnalysis
file. The only difference would be that on his machine the build tool would have created a slightly differentFileConverter
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 asBasicVirtualFileRef
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 theFileConverter
, and thus it might even be aware of the absolute paths.So when we look at the two types
VirtualFileRef
andVirtualFile
,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 ofVirtualFile
s. The files then gets wrapped by a datatype calledAbstractZincFile
, which extendsscala.reflect.io.AbstractFile
, which the compiler is able to compile. - trait VirtualFileWrite extends VirtualFile
-
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