Извлечение полного графа вызовов проекта scala (сложно)

Вот рабочий прототип, который выводит необходимые базовые данные на консоль в качестве доказательства концепции. http://goo.gl/oeshdx.

Как это работает

Я адаптировал концепции из @dk14 на верхнем шаблоне из макро-рай.

Рай макросов позволяет определить аннотацию, которая будет применяться к любому объекту с аннотациями в исходном коде. Оттуда у вас есть доступ к AST, который компилятор генерирует для исходного кода, и API отражения scala можно использовать для изучения информации о типе элементов AST. Квазицитаты (этимология от haskell или что-то в этом роде) используются для сопоставления AST для соответствующих элементов.

Подробнее о квазицитатах

Вообще важно отметить, что квазикавычки работают с AST, но они представляют собой странный на первый взгляд API, а не прямое представление AST (!). AST подбирается для вас аннотацией макросов рая, а затем квазикавычки являются инструментом для изучения имеющегося AST: вы сопоставляете, нарезаете и делите на кубики абстрактное синтаксическое дерево, используя квазикавычки.

Практическое замечание о квазицитатах заключается в том, что существуют фиксированные шаблоны квазицитатов для соответствия каждому типу scala AST — шаблон для определения класса scala, шаблон для определения метода scala и т. д. Все эти шаблоны представлены здесь, что упрощает сопоставление и деконструкцию доступный AST к его интересным составляющим. Хотя на первый взгляд шаблоны могут показаться устрашающими, в основном это просто шаблоны, имитирующие синтаксис scala, и вы можете свободно изменять в них имена переменных с добавлением $ на имена, которые вам больше нравятся.

Мне все еще нужно отточить используемые мной квазицитаты, которые в настоящее время не идеальны. Тем не менее, мой код, кажется, дает желаемый результат во многих случаях, и оттачивание совпадений до точности 95% может быть вполне выполнимым.

Пример вывода

found class B
class B has method doB
found object DefaultExpander
object DefaultExpander has method foo
object DefaultExpander has method apply
  which calls Console on object scala of type package scala
  which calls foo on object DefaultExpander.this of type object DefaultExpander
  which calls <init> on object new A of type class A
  which calls doA on object a of type class A
  which calls <init> on object new B of type class B
  which calls doB on object b of type class B
  which calls mkString on object tags.map[String, Seq[String]](((tag: logTag) => "[".+(Util.getObjectName(tag)).+("]")))(collection.this.Seq.canBuildFrom[String]) of type trait Seq
  which calls map on object tags of type trait Seq
  which calls $plus on object "[".+(Util.getObjectName(tag)) of type class String
  which calls $plus on object "[" of type class String
  which calls getObjectName on object Util of type object Util
  which calls canBuildFrom on object collection.this.Seq of type object Seq
  which calls Seq on object collection.this of type package collection
  .
  .
  .

Из этих данных легко увидеть, как можно сопоставить вызывающих и вызываемых абонентов и как можно отфильтровать или выделить цели вызовов за пределами источника проекта. Это все для scala 2.11. Используя этот код, нужно будет добавить аннотацию к каждому классу/объекту/и т. д. в каждом исходном файле.

Проблемы, которые остаются, в основном:

Оставшиеся проблемы:

1. Это вылетает после завершения работы. Зависимость от https://github.com/scalamacros/paradise/issues/67
2. Нужно найти способ в конечном итоге применить магию ко всем исходным файлам без ручного аннотирования каждого класса и объекта статической аннотацией. На данный момент это довольно незначительно, и, по общему признанию, есть преимущества в возможности контролировать классы, чтобы включать и игнорировать их в любом случае. Стадия предварительной обработки, которая вставляет аннотацию перед (почти) каждым определением исходного файла верхнего уровня, была бы одним из хороших решений.
3. Оттачивание сопоставителей таким образом, чтобы сопоставлялись все и только соответствующие определения - чтобы сделать это общим и надежным за пределами моего упрощенного и беглого тестирования.

Альтернативный подход к размышлению

acyclic напоминает о совершенно противоположном подходе, который все еще остается в области компилятора scala - он проверяет все символы, сгенерированные для источника компилятором (насколько я понимаю из источника). Что он делает, так это проверяет наличие циклических ссылок (подробное определение см. в репозитории). Предполагается, что к каждому символу прикреплена достаточная информация для построения графа ссылок, который должен генерировать acyclic.

Решение, основанное на этом подходе, может, если возможно, найти родительский владелец каждого символа, а не фокусироваться на графике подключений к исходным файлам, как это делает сама ациклика. Таким образом, с некоторыми усилиями он восстановит владение классом/объектом каждого метода. Не уверен, что этот дизайн не взорвется вычислительно, и как детерминистически получить класс, охватывающий каждый символ.

Положительным моментом будет то, что здесь нет необходимости в аннотациях макросов. Недостатком является то, что это не может разбрызгивать инструментарий времени выполнения, как довольно легко позволяет макрорай, что иногда может быть полезно.

Это требует более точного анализа, но для начала этот простой макрос напечатает все возможные приложения, но для этого нужен макрорай и все трассируемые классы должны иметь аннотацию @trace:

class trace extends StaticAnnotation { 
  def macroTransform(annottees: Any*) = macro tracerMacro.impl
}

object tracerMacro {

  def impl(c: Context)(annottees: c.Expr[Any]*): c.Expr[Any] = {

    import c.universe._
    val inputs = annottees.map(_.tree).toList
    def analizeBody(name: String, method: String, body: c.Tree) = body.foreach {
      case q"$expr(..$exprss)" => println(name + "." + method + ": " + expr)
      case _ =>
    }


    val output = inputs.head match {
      case q"class $name extends $parent { ..$body }" =>
        q"""
            class $name extends $parent {
              ..${
                   body.map {
                       case x@q"def $method[..$tt] (..$params): $typ = $body" =>
                         analizeBody(name.toString, method.toString, body)
                         x

                       case x@q"def $method[..$tt]: $typ = $body" =>
                         analizeBody(name.toString, method.toString, body)
                        x

                   }
                 }
            }
          """
      case x => sys.error(x.toString)
    }




    c.Expr[Any](output)
  }
}

Вход:

  @trace class MyF {
    def call(param: Int): Int = {
      call2(param)
      if(true) call3(param) else cl()
    }
    def call2(oaram: Int) = ???
    def cl() = 5
    def call3(param2: Int) = ???
  }

Вывод (как предупреждения компилятора, но вы можете выводить в файл вместо println):

  Warning:scalac: MyF.call: call2
  Warning:scalac: MyF.call: call3
  Warning:scalac: MyF.call: cl

Конечно, вы можете захотеть c.typeCheck(input) его (поскольку теперь expr.tpe для найденных деревьев равно null) и выяснить, к какому классу на самом деле принадлежит этот вызывающий метод, поэтому результирующий код может быть не таким тривиальным.

P.S. Макроаннотации дают вам непроверенное дерево (поскольку оно находится на более ранней стадии компиляции, чем обычные макросы), поэтому, если вы хотите что-то с проверкой типов - лучший способ - окружить фрагмент кода, который вы хотите проверить, вызовом какого-то вашего обычного макроса, и обработать его внутри этого макрос (можно даже передать некоторые статические параметры). Каждый обычный макрос внутри дерева, созданный макро-аннотацией, будет выполняться как обычно.

Изменить
Основная идея этого ответа заключалась в том, чтобы полностью обойти (довольно сложный) компилятор Scala и в конце извлечь граф из сгенерированных .class файлов. Оказалось, что декомпилятор с достаточно подробным выводом может свести проблему к простейшим манипуляциям с текстом. Однако при более детальном рассмотрении оказалось, что это не так. Можно было бы просто вернуться к исходной точке, но с запутанным кодом Java вместо исходного кода Scala. Таким образом, это предложение на самом деле не работает, хотя есть некоторое обоснование работы с окончательными файлами .class вместо промежуточных структур, используемых внутри компилятора Scala.
/Edit

Я не знаю, есть ли инструменты, которые делают это из коробки (я полагаю, что вы это проверили). У меня есть только очень приблизительное представление о том, что такое компилятор презентации. Но если все, что вам нужно, это извлечь граф с методами в качестве узлов и потенциальными вызовами методов в качестве ребер, у меня есть предложение для быстрого и грязного решения. Это будет работать, только если вы хотите использовать его для какой-то визуализации, это совсем не поможет вам, если вы хотите выполнить некоторые умные операции рефакторинга.

Если вы захотите попробовать создать такой генератор графов самостоятельно, это может оказаться намного проще, чем вы думаете. Но для этого вам нужно пройти полностью вниз, даже за пределы компилятора. Просто возьмите свои скомпилированные .class файлы и используйте для них что-то вроде декомпилятора Java CFR.

При использовании в одном скомпилированном файле .class CFR сгенерирует список классов, от которых зависит текущий класс (здесь в качестве примера я использую свой небольшой проект):

import akka.actor.Actor;
import akka.actor.ActorContext;
import akka.actor.ActorLogging;
import akka.actor.ActorPath;
import akka.actor.ActorRef;
import akka.actor.Props;
import akka.actor.ScalaActorRef;
import akka.actor.SupervisorStrategy;
import akka.actor.package;
import akka.event.LoggingAdapter;
import akka.pattern.PipeToSupport;
import akka.pattern.package;
import scala.Function1;
import scala.None;
import scala.Option;
import scala.PartialFunction;
...
(very long list with all the classes this one depends on)
...
import scavenger.backend.worker.WorkerCache$class;
import scavenger.backend.worker.WorkerScheduler;
import scavenger.backend.worker.WorkerScheduler$class;
import scavenger.categories.formalccc.Elem;

Затем он выдаст какой-то ужасно выглядящий код, который может выглядеть так (небольшой отрывок):

public PartialFunction<Object, BoxedUnit> handleLocalResponses() {
    return SimpleComputationExecutor.class.handleLocalResponses((SimpleComputationExecutor)this);
}

public Context provideComputationContext() {
    return ContextProvider.class.provideComputationContext((ContextProvider)this);
}

public ActorRef scavenger$backend$worker$MasterJoin$$_master() {
    return this.scavenger$backend$worker$MasterJoin$$_master;
}

@TraitSetter
public void scavenger$backend$worker$MasterJoin$$_master_$eq(ActorRef x$1) {
    this.scavenger$backend$worker$MasterJoin$$_master = x$1;
}

public ActorRef scavenger$backend$worker$MasterJoin$$_masterProxy() {
    return this.scavenger$backend$worker$MasterJoin$$_masterProxy;
}

@TraitSetter
public void scavenger$backend$worker$MasterJoin$$_masterProxy_$eq(ActorRef x$1) {
    this.scavenger$backend$worker$MasterJoin$$_masterProxy = x$1;
}

public ActorRef master() {
    return MasterJoin$class.master((MasterJoin)this);
}

Здесь следует заметить, что все методы имеют полную сигнатуру, включая класс, в котором они определены, например:

Scheduler.class.schedule(...)
ContextProvider.class.provideComputationContext(...)
SimpleComputationExecutor.class.fulfillPromise(...)
SimpleComputationExecutor.class.computeHere(...)
SimpleComputationExecutor.class.handleLocalResponses(...)

Так что, если вам нужно быстрое и грязное решение, вполне возможно, что вы могли бы обойтись всего ~ 10 строками awk, grep, sort и uniq волшебства, чтобы получить хорошие списки смежности со всеми вашими классами в качестве узлов и методами в качестве ребер. .

Я никогда не пробовал, это просто идея. Я не могу гарантировать, что декомпиляторы Java хорошо работают с кодом Scala.