Add a dotty-interfaces package

[smarter]

We introduce a new entry point for the compiler in
dotty.tools.dotc.Driver:

def process(args: Array[String], simple: interfaces.SimpleReporter,
  callback: interfaces.CompilerCallback): interfaces.ReporterResult

Except for args which is just an array, the argument types and return
type of this method are Java interfaces defined in a new package called
dotty-interfaces which has a stable ABI. This means that you can
programmatically run a compiler with a custom reporter and callbacks
without having to recompile it against every version of dotty: you only
need to have dotty-interfaces present at compile-time and call the
process method using Java reflection.

See test/test/InterfaceEntryPointTest.scala for a concrete example.

This design is based on discussions with the IntelliJ IDEA Scala plugin
team. Thanks to Nikolay Tropin for the discussions and his PR
proposal (see #1011).

Review by @sjrd
/cc @niktrop

[sjrd]

JavaDoc style is different than Scaladoc. See http://www.oracle.com/technetwork/articles/java/index-137868.html#format
It should therefore be:

/**
 * Set of callbacks ...
 *
 * You should ...
 * ...
 */

(same everywhere there are JavaDocs, obviously.)

[smarter]

I'm not against changing it, but isn't it nicer to keep the style consistent across Dotty? javadoc seems to interpret this style correctly so I don't see any downside.

[sjrd]

I don't have any strong feelings either way. We can keep it like this.

[sjrd]

What command tests InterfaceEntryPointTest and OtherEntryPointsTest?

[sjrd]

That's all.

[niktrop]

This import is unused.

[smarter]

What command tests InterfaceEntryPointTest and OtherEntryPointsTest?

It will be run by partest (as well as test), you can run just one of these test classes with
test-only test.InterfaceEntryPointTest (you can run a single test method with
test-only -- --tests=runCompilerWithContext)

[sjrd]

It will be run by partest (as well as test)

OK.

[niktrop]

I run dotty compiler from IDEA with this version of dotty interface. We can make a build of scala plugin with Dotty compiler as soon as you merge this PR and publish jars.

[smarter]

@niktrop : Cool! Note that since this is very experimental we might have to break the ABI, I think that's okay until we have a real release of Dotty.

[smarter]

@sjrd: what do you think of adding an AbstractFile interface?

public interface AbstractFile {
  String name();
  String path();
  Optional<File> file();
}

and we would change the SourceFile interface to inherit from that:

public interface SourceFile extends AbstractFile {
  /** The content of this file as seen by the compiler. */
  char[] content();
}

Then we could have:

default void onClassGenerated(SourceFile source, AbstractFile generatedClass, String className) {};

[sjrd]

Yes, good idea.

[smarter]

Hmm, but I can't do that without changing the definition of scala.reflect.io.AbstractFile to inherit from that interface, we could do this in our scalac fork but that doesn't seem like a good idea. Alternatively I could wrap a scala.reflect.io.AbstractFile into a dotty.tools.dotc.interfaces.AbstractFile everytime we call a callback method:

def wrapAbstractFile(absfile: AbstractFile) = new interfaces.AbstractFile {
  def name = absfile.name
  def path = absfile.path
  def file = if (absfile.file != null) Optional.of(absfile.file) else Optional.none
}

What do you think?

[sjrd]

Yes, you'll probably have to wrap. You'll lose identity, though, which should be documented (like "Do not rely on the identity of AbstractFiles")

[odersky]

We already use an AbstractFile abstraction, the one reflect.io. SourceFile
contains an AbstractFile rather than inheriting from it (either way works
OK IMO. I believe we should make a new one only if we are sure that we
cannot use the reflect.io one for some reason.

• Martin

On Thu, Feb 25, 2016 at 6:42 PM, Guillaume Martres <[email protected]

wrote:

@sjrd https://github.com/sjrd: what do you think of adding an
AbstractFile interface?

public interface AbstractFile {
String name();
String path();
Optional file();
}

and we would change the SourceFile interface to inherit from that:

public interface SourceFile extends AbstractFile {
/** The content of this file as seen by the compiler. */
char[] content();
}

Then we could have:

default void onClassGenerated(SourceFile source, AbstractFile generatedClass, String className) {};

—
Reply to this email directly or view it on GitHub
#1125 (comment).

Martin Odersky
EPFL

[sjrd]

if we are sure that we cannot use the reflect.io one for some reason.

The reflect.io one is tight to a Scala binary version. This interfaces package is pure-Java, so that it is not affected by any binary compatibility issue.

[odersky]

Ah, yes, that is a good enough reason, I think.

On Sat, Feb 27, 2016 at 2:24 PM, Sébastien Doeraene <
[email protected]> wrote:

if we are sure that we cannot use the reflect.io one for some reason.

The reflect.io one is tight to a Scala binary version. This interfaces
package is pure-Java, so that it is not affected by any binary
compatibility issue.

—
Reply to this email directly or view it on GitHub
#1125 (comment).

Martin Odersky
EPFL

[smarter]

@sjrd AbstractFile interfaces added, I find CompilerCallback clearer than CompilerListener so I'm not motivated to rename it :).

[sjrd]

LGTM

I find CompilerCallback clearer than CompilerListener so I'm not motivated to rename it :).

Fair enough.