|
|
|
Re: Override import behavior to handle C-style includes [message #1806227 is a reply to message #1806226] |
Mon, 06 May 2019 13:58 |
|
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 |
Adriano Carvalho 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 #1806272 is a reply to message #1806255] |
Tue, 07 May 2019 09:45 |
Adriano Carvalho 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 #1806312 is a reply to message #1806287] |
Tue, 07 May 2019 15:47 |
Adriano Carvalho 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
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03090 seconds