Расширенное справочное разрешение в xtext, как правильно настроить область видимости / индекс? - PullRequest
0 голосов
/ 05 августа 2020

Я пытаюсь показать минимальный рабочий пример, описывающий мою проблему:

Грамматика

Это xtext грамматика, которую я создал для этого примера. (Настоящая грамматика, конечно, намного сложнее и также включает в себя продвинутый язык выражений)

grammar org.example.dsl.DSL with org.eclipse.xtext.common.Terminals

generate dsl "http://www.example.org/dsl/DSL"

Model:
  elements+=Declaration*
;

QualifiedName:
  ID ('.' ID)*
;

Declaration:
  SimpleTypeDeclaration |
  SectionDeclaration |
  FieldDeclaration
;

SimpleTypeDeclaration:
  "type" name=ID "=" primitive=IntegerType
;

IntegerType
  {IntegerType} "int"
;

SectionDeclaration:
  "section" name=ID "{"
    elements+=FieldDeclaration*
  "}"
;

TypeDeclaration:
  SimpleTypeDeclaration |
  SectionDeclaration
;

FieldDeclaration:
  name=ID ":" type=[TypeDeclaration|QualifiedName] ("=" value=ValueExpression)?
;

ValueExpression:
  FieldReference |
  SimpleValue
;

FieldReference:
  ref=[FieldDeclaration|QualifiedName]
;

SimpleValue:
  {SimpleValue} "sentinel"
;

Example-Code в Example-Language

Это пример кода на языке I описано выше.

type Foo = int

section A {
  foo: Foo = sentinel
}

section B {
  a: A

  // here I want to assign the value of a subfield of `a`
  // to fubar
  fubar: Foo = a.foo // crucial point
} 

Глобальный индекс фрагмента кода примера

Индексатор по умолчанию фрагмента кода примера сгенерирует следующий индекс глобальной области для ссылки:

[Foo, A, A.foo, B, B.a, B.fubar]

Таким образом, с правильной областью видимости я мог бы ссылаться на все эти объекты по этим идентификаторам в моем коде с разрешением ссылки.

Но crucial point в коде фрагмент не будет разрешен, потому что B.a.foo соответственно a.foo не будет в индексе.

То, что я думал и пробовал до сих пор (неполные решения)

  1. Я подумал о настройке индекса, чтобы он дополнительно помещал B.a.foo в индекс.

    • , но это могло бы засорять индекс потенциально таким количеством ненужных URI ресурсов, что я не когда-либо захотелось ссылаться на глобальную область видимости.
    • (например, я просто хочу иметь возможность ссылаться на подполя полей из раздела, из которого я на него ссылаюсь)
  2. Создайте новое Правило в грамматике под названием Selection => сделайте квалифицированный выбор полей явным, предоставив настраиваемое ScopeProvider. Но есть некоторые проблемы, с которыми я столкнулся:

    • Если я все еще предоставляю возможность ссылаться на все через QualifiedName s, грамматика и разрешение всегда будут думать, что это ссылка на тип, как и раньше, и не буду спрашивать мой пользовательский поставщик области видимости чтобы предоставить ссылку для правила Selection, которое перегружает оператор точки (.)
    • Если я удалю механизм ссылок [TypeDeclaration|QualifiedName], заменив его на [TypeDeclaration|ID], мне придется настроить охват для каждого базового типа и подссылки и не будет использовать мощное разрешение квалифицированных имен по умолчанию xtext.

Мой вопрос сейчас

Кто-нибудь знает о стандартное или лучшее решение проблемы, которую я описал?

...