-------- Original-Nachricht -------- Betreff: Re: [Trex-devel] Usage of Scope.resolve() and trunk vs. release Datum: Fri, 20 Oct 2006 16:09:29 +0200 (CEST) Von: Jens Bräuer jensb@cs.tu-berlin.de Antwort an: jensb@cs.tu-berlin.de An: Benjamin Zeiss zeiss@cs.uni-goettingen.de Referenzen: BAY13-F206A1721A5B4BEBBABFD50B90E0@phx.gbl 29843.194.114.62.34.1161273889.squirrel@www.muppet-show 4537AF86.4090408@cs.uni-goettingen.de
Hi Benjamin,
And: Any plans when semanticalAnalysis will be back again ? ;-)
Our development resources for TRex are currently very limited. So i don't want to promise anything. The problem is that currently, the semantical analysis reports false errors in the scope visibility analysis (in the SIP test suite for example), because we don't have the TTCN-3 built-in functions implemented (int2str etc.). Hence, it is currently disabled until someone addresses this issue. The issues isn't too big though.
There seems to be another problem when using the current version of semanticalAnalysis. Variables declared in the component are not resolved properly. Had a look onto TTCN3SymbolTableTreeParser but i was unable to find anything useful.
The below example produces:
1079 [main] WARN de.tuberlin.cs.jensb - D:\jbr\svn_trunk_uni\code\TRexTest\src\de\tuberlin\cs\jensb\01.ttcn3:13:0: j is not declared
When logging the exceptions via log4j.
[Sample posted again for completeness]
--- 01.ttcn3 --- module test { type component A { var integer j; var integer i; }
testcase foo() runs on A { var integer i := 0; j := i; }
control { execute(foo()); } } --- /01.ttcn3 ---
by the way: the website here contains some additional maybe useful documentation on the symbol table stuff.
http://www.trex.informatik.uni-goettingen.de/trac/wiki/SymbolTableDocumentat...
Already had a look on it and i clearly states, that resolve(String) is deprecated. ;-) Sorry, that i missed that point.
Greetings, Jens
Hi Jens,
Benjamin Zeiss schrieb:
There seems to be another problem when using the current version of semanticalAnalysis. Variables declared in the component are not resolved properly. Had a look onto TTCN3SymbolTableTreeParser but i was unable to find anything useful.
I'll check that on monday or maybe later the weekend.
Benjamin Zeiss wrote:
Hi Jens,
Benjamin Zeiss schrieb:
There seems to be another problem when using the current version of semanticalAnalysis. Variables declared in the component are not resolved properly. Had a look onto TTCN3SymbolTableTreeParser but i was unable to find anything useful.
I'll check that on monday or maybe later the weekend.
Debugged a bit within the last hours. As far as i got it, the problem lies within the AST construction and not in the resolve-Algorithm. Inspecting the data-structures i found, that the "knownScopes"-attribute is always an empty ArrayList, but it should point to the componentScope.
There is another thing i dont understand in the current implementation:
Having parsed this file and created the SymbolTable from the AST:
--- testfile ---- module test {
type port myPort message { out charstring };
type component AComponent { var integer jInstance := 4; port myPort myPortRef; }
testcase fooTestcase() runs on AComponent system AComponent { var integer i := 0; var integer j := 3; jInstance := i; } control { execute(fooTestcase()); } } ------------------
Now i wanted to play round with the data-structures a bit:
----- code ----- Scope moduleBodyScope = rootNode.getScope().getChildren().get(0); Scope componentScope = moduleBodyScope.getChildren().get(1); Scope testcaseScope = moduleBodyScope.getChildren().get(2); Scope testcaseBodyScope = testcaseScope.getChildren().get(0);
System.out.println(testcaseBodyScope.resolve("i")); System.out.println(testcaseBodyScope.resolve("j")); System.out.println(testcaseBodyScope.getSymbolTable()); ------------------
Produces the following output:
----- stdout ---- i null Symbol Table Contents: key: i -----------------
Looks like the scope i named "testcaseBodyScope" is actually not the scope of the testcaseBody. Looks like a new scope is introduced by the variable declaration. Is this correct/intended ? If so, what scope should i use to resolve all variables and references named in the body of a testcase or function ?
btw: i know i was told not to used the resolve(String)-Method ;-) But looking at the symboltable returned by testcaseBodyScope.getSymbolTable() the question would be the same. (?)
Greetings, Jens
Hi Jens,
Jens Bräuer schrieb:
Debugged a bit within the last hours. As far as i got it, the problem lies within the AST construction and not in the resolve-Algorithm. Inspecting the data-structures i found, that the "knownScopes"-attribute is always an empty ArrayList, but it should point to the componentScope.
Well i just checked it. When you paste that code into TRex and hover over jInstance or Acomponent references with the mouse cursor, you'll get the type information. That basically means that the symbol table works correctly for your code snippet (in fact, i would have been surprised if it didn't - the only problem in the symbol table i currently know of are problems with enums in some cases). So there must be something else wrong in your code. My guess is that you miss to call the postprocess method on the TTCN3Analyzer after all files have been analyzed. This is necessary for connecting the known scopes.
Now i wanted to play round with the data-structures a bit:
----- code ----- Scope moduleBodyScope = rootNode.getScope().getChildren().get(0); Scope componentScope = moduleBodyScope.getChildren().get(1); Scope testcaseScope = moduleBodyScope.getChildren().get(2); Scope testcaseBodyScope = testcaseScope.getChildren().get(0);
System.out.println(testcaseBodyScope.resolve("i")); System.out.println(testcaseBodyScope.resolve("j")); System.out.println(testcaseBodyScope.getSymbolTable());
Produces the following output:
----- stdout ---- i null Symbol Table Contents: key: i
Looks like the scope i named "testcaseBodyScope" is actually not the scope of the testcaseBody. Looks like a new scope is introduced by the variable declaration. Is this correct/intended ? If so, what scope should i use to resolve all variables and references named in the body of a testcase or function ?
It is correct that each new variable definition creates a new scope. It's like that by design and it is easy to tell why. Here is an example:
integer a := b; integer b := 0;
This is incorrect code, because b is used before it is declared and must not visible in the first line (if it is not available in some parent scope). If we put both of them into a single symbol table, such a notation would actually be allowed.
I think the problem is that you are trying to use the symbol table for something that it's not supposed to be used. The symbol table merely provides information about the identifiers which are visible in a specific position of the code. You should not try to use it for anything else like navigation within the code. The symbol table is the wrong facility to do that.
Ideally, we would have an object model like the TTWorkbench EMF metamodel which could be used for the navigation within the source code. This would be created next to the syntax tree. However, currently, the only underlying model is the syntax tree consisting of LocationAST node objects. You could easily write a class to make it easier to find specific positions in the tree or source (the ASTUtil class already contains some of those).
Hope this helps.
Bye Benjamin
Benjamin Zeiss wrote:
Debugged a bit within the last hours. As far as i got it, the problem lies within the AST construction and not in the resolve-Algorithm. Inspecting the data-structures i found, that the "knownScopes"-attribute is always an empty ArrayList, but it should point to the componentScope.
Well i just checked it. When you paste that code into TRex and hover over jInstance or Acomponent references with the mouse cursor, you'll get the type information. That basically means that the symbol table works correctly for your code snippet (in fact, i would have been surprised if it didn't - the only problem in the symbol table i currently know of are problems with enums in some cases). So there must be something else wrong in your code. My guess is that you miss to call the postprocess method on the TTCN3Analyzer after all files have been analyzed. This is necessary for connecting the known scopes.
Thanks ! Calling postprocess solved the "problem". Now all symbols are resolved properly.
It is correct that each new variable definition creates a new scope. It's like that by design and it is easy to tell why. Here is an example:
integer a := b; integer b := 0;
This is incorrect code, because b is used before it is declared and must not visible in the first line (if it is not available in some parent scope). If we put both of them into a single symbol table, such a notation would actually be allowed.
You are right. I missed totally that point.
So, thanks for the two hints. Think it could have been days till i would have found the postprocess() thing.
Greetings, Jens
trex-devel@informatik.uni-goettingen.de
-
Benjamin Zeiss -
Jens Bräuer