[PoC] Generate IR definitions with annotation processor

[Akirathan]

Closes #11498

Pull Request Description

Introduces runtime-parser-processor annotation processor that processes interfaces annotated with @IRNode.

Introduces these 3 new sbt projects:

• runtime-parser-dsl is a project that contains only the annotation definitions, has no dependencies.
• runtime-parser-processor is a project that contains the definition of the annotation processor. Has no dependencies.
• runtime-parser project now depends on runtime-parser-dsl and runtime-parser-processor.

Important Notes

Links to the docs:

• Entry point to the annotation processor: IRNodeClassGenerator.
• org.enso.runtime.parser.dsl package that contains annotation definitions

Examples of used annotations:

• JName.java - this should ultimately replace Name.scala
• JExpression.java - this should ultimatelly replace Expression.scala

To see the generated code, it is enough to sbt> runtime-parser/compile. All the tests are inside the runtime-parser-processor-test project.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• Run SigTest on runtime-compiler on develop and on this PR.
• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.

[JaroslavTulach]

One of the issues with newly generated Java classes is the way to consume them from existing Scala passes. Preferably we do it in a way that doesn't require changes to the existing Scala code. Once I asked

"Knowing how to generate a Java class to be able to apply and unapply it would be great!"

@hubertp has provided following advice when it comes to pattern matching:

package org.enso.compiler.core.ir;

import org.enso.compiler.core.IR;
import org.enso.compiler.core.Identifier;
import scala.Option;
import scala.PartialFunction;
import scala.Tuple2$;
import scala.collection.immutable.List;

import java.util.UUID;
import java.util.function.Function;

public class Foo implements Expression {

    private final Integer a;
    private final String b;

    public Foo(Integer a, String b) {
        this.a = a;
        this.b = b;
    }

    public static scala.Option<scala.Tuple2<Integer, String>> unapply(Object x) {
        if (x instanceof Foo f) {
            return Option.apply(Tuple2$.MODULE$.apply(f.a, f.b));
        } else {
            return Option.empty();
        }
    }

and then

package org.enso.compiler.core.ir

object TestPattern {

  def testMe(x: Object): Unit = {
    x match {
      case Foo(a, b) =>
        println("A " + a + ", B " + b);
      case _ =>
        println("nope")
    }
  }

  def main(args: Array[String]): Unit = {
    testMe(new Foo(1, "foo"))
  }

}

"works just fine" according to @hubertp.

[Akirathan]

An abandoned idea to generate Scala classes is the following commits that are now reverted:

• d2bb8c3
• 68a070b

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-10-21):

Progress: - IRProcessor traverser super interfaces and collects all the fields

• Reverted back to Java class generation It should be finished by 2024-11-07.

[Akirathan]

All the required Engine tests are green for the revision that migrated Empty to an interface annotated with @IRNode. This was the very first step that proves that such incremental migration is possible, at least for the simplest possible IR element.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-12-02):

Progress: - Migrating Empty to a Java interface annotated with @IRNode.

• aa345ed
• If all goes well, I will try to migrate CallArgument as well.
• All Engine tests are green - [PoC] Generate IR definitions with annotation processor  #11267 (comment)
  • The migration of Empty was successful. It should be finished by 2024-12-15.

[JaroslavTulach]

All the required Engine tests are green for the revision that migrated Empty to an interface annotated with @IRNode.

Well, this test is failing and the failure is related.

Shouldn't the DSL dependency be just provided for runtime-parser? That would be the easiest fix.