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