REPL code review

[Jan Lahoda]

On 11.9.2015 19:27, Maurizio Cimadamore wrote:
>
>
> On 11/09/15 18:01, Jan Lahoda wrote:
>> The general intent of scopeContent is to gather all elements that are
>> defined at the given place (for which the Scope was created).
>> Scope.getLocalElements only returns elements that are local to the
>> scope - for example for a Scope that was created for a location inside
>> a method, the getLocalElements won't include the imported elements.
> ah - thx for the clarification; I get that imported elements will be
> missing, but I believe elements declared in enclosing scopes will still
> be there? I.e. after all, a scope will have its 'next' field pointing to
> the enclosing scope (which is the scope of the outer env); but I get
> that there are corner cases in which this 1-1 mapping breaks.

The hierarchies of api Scopes (com.sun.tools.tree.Scope) and 
implementation Scopes (com.sun.tools.javac.code.Scope) differ. Consider 
this case:

class X {
      int i;
      public void test() {
            int j; //here
      }
}

The implementation Scope at the marked position will have several outer 
Scopes with less and less elements defined. But the "outer/next Scope" 
hierarchy will stop at the class declaration.

For API Scope at the marked position, the API Scope.getEnclosingScope 
will jump directly out of the class declaration - the API 
Scope.getEnclosingScope is based on Env.outer (see 
JavacScope.getEnclosingScope). The implementation Scope kept internally 
in the API Scope (via an Env) is flattened in Attr.copyScope, so it does 
not have any outer Scope (but it indeed contains all the elements 
defined on the path from the enclosing class to the point where the 
Scope was requested). So, in the API Scope, doing getEnclosingScope and 
getLocalElements should not lead to duplicated elements in the result.

Jan

>
> Maurizio