Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Override import behavior to handle C-style includes
Override import behavior to handle C-style includes [message #1806220] Mon, 06 May 2019 10:25 Go to next message
Adriano Carvalho is currently offline Adriano CarvalhoFriend
Messages: 54
Registered: November 2018
Member
Hello,

I am supporting a legacy language which relies on C-style includes.

Example:
include System\library.inc

I would like to override the default import behavior such that the above statement does two things:
1. Imports the contents of the specified file/model.
2. Creates a new reference "include" (in the including file/model) pointing to the root of the included file/model.

How can I do this?

Thanks in advance.

Best regards.
Re: Override import behavior to handle C-style includes [message #1806225 is a reply to message #1806220] Mon, 06 May 2019 12:41 Go to previous messageGo to next message
Karsten Thoms is currently offline Karsten ThomsFriend
Messages: 762
Registered: July 2009
Location: Dortmund, Germany
Senior Member

You'll likely want to bind org.eclipse.xtext.scoping.impl.ImportUriGlobalScopeProvider as IGlobalScopeProvider and provide hyperlinks to the referenced location by customizing HyperlinkHelper.

The ImportUriGlobalScopeProvider does not work with transitive includes, and I recommend that you don't add this requirement. Otherwise you'll have to implement them. This (german) blog post tells how to do that: https://blogs.itemis.com/de/in-5-minuten-zur-dsl-mit-transitiven-importen-in-xtext
Re: Override import behavior to handle C-style includes [message #1806226 is a reply to message #1806225] Mon, 06 May 2019 13:23 Go to previous messageGo to next message
Adriano Carvalho is currently offline Adriano CarvalhoFriend
Messages: 54
Registered: November 2018
Member
Thanks Karsten.

Let me check if I understand you correctly...
I am by far, not an Xtext expert.

If I bind the IGlobalScopeProvider and provide a custom HyperlinkHelper as you've mentioned, the elements in the included/imported file can be referenced by the including file. This way, however, those elements included by the included file cannot be referenced; unless, I follow the post you have indicated.

Is this correct?
Re: Override import behavior to handle C-style includes [message #1806227 is a reply to message #1806226] Mon, 06 May 2019 13:58 Go to previous messageGo to next message
Karsten Thoms is currently offline Karsten ThomsFriend
Messages: 762
Registered: July 2009
Location: Dortmund, Germany
Senior Member

Basically, yes. The ImportUriGlobalScopeProvider is a global scope provider that relies on imported URIs instead of namespace imports, which is the default. It does not make hyperlinks available, though. And the idea to make transitive includes possible, although discouraged, is described in the blog post. You may search for languages on GitHub or elsewhere which make use of ImportUriGlobalScopeProvider for further reference.
Re: Override import behavior to handle C-style includes [message #1806247 is a reply to message #1806227] Mon, 06 May 2019 20:35 Go to previous messageGo to next message
Adriano Carvalho is currently offline Adriano CarvalhoFriend
Messages: 54
Registered: November 2018
Member
Regarding point 1 in my original post, I think I have enough information to solve my issue. Thanks Karsten.

However, there's still point 2. I need not only to be able to refer to the contents of the included file but also need that the included file is "contained" within the including file: a reference to the root element of the included file (at the point of inclusion).

In other words, the generated code for the grammar rule:

IncludeStmt: "include" importURI=STRING ;

should add to the model an IncludeStmt (with attribute importURI as a reference to the corresponding root element).

How should I do this?
Can I do this by customizing some Xtext component?
Or do I need to change the generated ".g file or maybe some other file?

[Updated on: Tue, 07 May 2019 09:09]

Report message to a moderator

Re: Override import behavior to handle C-style includes [message #1806255 is a reply to message #1806247] Tue, 07 May 2019 04:07 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
No you need to implement that manually

Can you be more specific what you. Mean by included
What about simply resolve the uri and get the resource

(Have a. Look what the global scope provider does)


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

[Updated on: Tue, 07 May 2019 04:09]

Report message to a moderator

Re: Override import behavior to handle C-style includes [message #1806272 is a reply to message #1806255] Tue, 07 May 2019 09:45 Go to previous messageGo to next message
Adriano Carvalho is currently offline Adriano CarvalhoFriend
Messages: 54
Registered: November 2018
Member
I have made a mistake. Sorry. The default behavior does create IncludeStmt with an "importURI" attribute.

Now my question becomes:

If instead of:
IncludeStmt: "include" importURI=STRING ;
I use:
IncludeStmt: "include" importURI=[ExternalModel|Location] ;

Where:
- ExternalModel represents the root of included* model and
- Location represents the location of the file/model in the filesystem (or include path).
(Both implicitly provided by the global scope provided.)

Is there any possibility of this working "out-of-the-box"?


My previous full answer. You can ignore. Sorry once more.

Quote:
You've said "What about simply resolve the uri and get the resource". Sorry to ask but: When? And then what? Would that (1) make the "contents" of the included* file accessible to the including* file and (2) create an IncludeStmt element with an importURI as a reference to the included* file's root element?

What I would like is that the rule

IncludeStmt: "include" importURI=STRING ;

(1) provides the default/expected functionality for "importURI" rules (in my case, to make the "contents" of the included* file accessible to the including* file) and at the same time
(2) provides a behavior slightly different to the behavior given by "normal" grammar rules with no "importURI" (that is, to create an IncludeStmt element with an importURI attribute as a reference to the included* file's root element).

Maybe a more appropriate rule would be:

IncludeStmt: "include" importURI=[ExternalModel|Location] ;

Where:
- ExternalModel represents the root of included* model and
- Location represents the location of the file/model in the filesystem (or include path).
(Both implicitly provided by the global scope provided.)

The issue with the default behavior is that a rule with importURI will not create any element in the model. In my case, however, I need this. As in C, the location of inclusion is important.

Isn't the global scope provider used during the linking stage?
Wouldn't I need the IncludeStmt to have been created already?


--
*The "including" file (or model) is the file that includes the "included" file. Example:

including.ext
...
include "included.ext"
...

included.txt
...

[Updated on: Tue, 07 May 2019 09:53]

Report message to a moderator

Re: Override import behavior to handle C-style includes [message #1806287 is a reply to message #1806272] Tue, 07 May 2019 11:59 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
IncludeStmt: "include" importURI=[ExternalModel|Location] ;

will work if you are about nameproviders


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Override import behavior to handle C-style includes [message #1806312 is a reply to message #1806287] Tue, 07 May 2019 15:47 Go to previous messageGo to next message
Adriano Carvalho is currently offline Adriano CarvalhoFriend
Messages: 54
Registered: November 2018
Member
Using the grammar that follows, references across files no longer work.
The IncludeDecl rules is only a quick and dirty way to "simulate" names implicitly provided by the global scope provider.

Quote:

grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.common.Terminals

generate myDsl "http://www.xtext.org/example/mydsl/MyDsl"

Model:
stmt+=Stmt*
;

Stmt:
(DataType | DataInstance | ImportDecl | ImportStmt) ';'
;

DataType:
'data' name=ID ('{'
stmt+=Stmt*
'}')?
;

DataInstance:
type=[DataType] name=ID
;

ImportDecl:
"includedecl" name=STRING
;

ImportStmt:
"include" importURI=[ImportDecl|STRING]
;


Example:

primitivetype.mydsl:
Quote:

data int;
data char;


sample.mydsl:
Quote:

includedecl "primitivetype.mydsl";
includedecl "module.mydsl";

include "primitivetype.mydsl";

int abc; // ERROR: Couldn't resolve reference to DataType 'int'.

data manyint {
int a1; // ERROR: Couldn't resolve reference to DataType 'int'.
int a2; // ERROR: Couldn't resolve reference to DataType 'int'.
int a3; // ERROR: Couldn't resolve reference to DataType 'int'.
};

manyint m1;

data manymanyint {
manyint a1;
manyint a2;
manyint a3;
};


I added MyDslQualifiedNameProvider shown below and it still doesn't work (that is, references across files no longer work, as shown below).
Is this what you meant with "nameprovider" right?

Quote:

class MyDslQualifiedNameProvider extends DefaultDeclarativeQualifiedNameProvider {

@Inject
IQualifiedNameConverter converter = new IQualifiedNameConverter.DefaultImpl();

def QualifiedName qualifiedName(ImportStmt ele) {
val nodes = NodeModelUtils.findNodesForFeature(ele, MyDslPackage.Literals.IMPORT_STMT__IMPORT_URI)
for (n : nodes) {
val text = NodeModelUtils.getTokenText(n)
if (text !== null) {
return converter.toQualifiedName(text)
}
}
return null
}
}


BTW the IncludeStmt element is not shown anymore. in the outline.

I have attached my development and runtime workspaces.

Can the problem be my "quick and dirty way to simulate names implicitly provided by the global scope provider"?

[Updated on: Tue, 07 May 2019 15:50]

Report message to a moderator

Re: Override import behavior to handle C-style includes [message #1806317 is a reply to message #1806312] Tue, 07 May 2019 16:58 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
you did get me wrong.
id you want to refer to a
Model
IncludeStmt: "include" importURI=[ExternalModel|Location] ;
you need to change the name for ExternalModel
in the nameprovider to
"primitivetype.mydsl";

therefore you can ask the model for its resource and that for its uri


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Override import behavior to handle C-style includes [message #1807198 is a reply to message #1806317] Fri, 24 May 2019 14:10 Go to previous message
Adriano Carvalho is currently offline Adriano CarvalhoFriend
Messages: 54
Registered: November 2018
Member
Attached follows what I have got so far:
- C-style includes
- Transitive includes
- Include statement as a reference to the included Model

I have only worked under "test-include\org.xtext.example.mydsl\src\org\xtext\example\mydsl". No need to look elsewhere (it was automatically generated).
  • Attachment: ws.rar
    (Size: 1.67MB, Downloaded 86 times)
Previous Topic:Can Xtext be used to create general-purpose programming languages?
Next Topic:Deployed xText IDE does not work
Goto Forum:
  


Current Time: Thu Apr 18 23:25:38 GMT 2024

Powered by FUDForum. Page generated in 0.03090 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top