t

xsbti

VirtualFileRef

trait VirtualFileRef extends AnyRef

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.

Linear Supertypes
AnyRef, Any
Known Subclasses
BasicVirtualFileRef, PathBasedFile, VirtualDirectory, VirtualFile, VirtualFileWrite
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. VirtualFileRef
  2. AnyRef
  3. Any
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. All

Abstract Value Members

  1. abstract def id(): String

    Returns unique identifier for the file.

    Returns unique identifier for the file. For Java compilation it needs to contain the path structure matching the package name for example com/acme/Foo.java.

    It also must end with the same value as name(), Java files must end with ".java", and Scala files must end with ".scala".

  2. abstract def name(): String

    Returns "file name" for the file.

    Returns "file name" for the file. Java files must end with ".java", and Scala files must end with ".scala".

  3. abstract def names(): Array[String]

Concrete Value Members

  1. final def !=(arg0: Any): Boolean
    Definition Classes
    AnyRef → Any
  2. final def ##(): Int
    Definition Classes
    AnyRef → Any
  3. final def ==(arg0: Any): Boolean
    Definition Classes
    AnyRef → Any
  4. final def asInstanceOf[T0]: T0
    Definition Classes
    Any
  5. def clone(): AnyRef
    Attributes
    protected[lang]
    Definition Classes
    AnyRef
    Annotations
    @throws( ... ) @native()
  6. final def eq(arg0: AnyRef): Boolean
    Definition Classes
    AnyRef
  7. def equals(arg0: Any): Boolean
    Definition Classes
    AnyRef → Any
  8. def finalize(): Unit
    Attributes
    protected[lang]
    Definition Classes
    AnyRef
    Annotations
    @throws( classOf[java.lang.Throwable] )
  9. final def getClass(): Class[_]
    Definition Classes
    AnyRef → Any
    Annotations
    @native()
  10. def hashCode(): Int
    Definition Classes
    AnyRef → Any
    Annotations
    @native()
  11. final def isInstanceOf[T0]: Boolean
    Definition Classes
    Any
  12. final def ne(arg0: AnyRef): Boolean
    Definition Classes
    AnyRef
  13. final def notify(): Unit
    Definition Classes
    AnyRef
    Annotations
    @native()
  14. final def notifyAll(): Unit
    Definition Classes
    AnyRef
    Annotations
    @native()
  15. final def synchronized[T0](arg0: ⇒ T0): T0
    Definition Classes
    AnyRef
  16. def toString(): String
    Definition Classes
    AnyRef → Any
  17. final def wait(): Unit
    Definition Classes
    AnyRef
    Annotations
    @throws( ... )
  18. final def wait(arg0: Long, arg1: Int): Unit
    Definition Classes
    AnyRef
    Annotations
    @throws( ... )
  19. final def wait(arg0: Long): Unit
    Definition Classes
    AnyRef
    Annotations
    @throws( ... ) @native()

Inherited from AnyRef

Inherited from Any

Ungrouped