hg: tiered-attrib/dev/langtools: do attribute the site of a field access expression inside a stuck lambda body

[Maurizio Cimadamore]

I think I see what you are trying to do here, but I think your are 
approaching the problem from the wrong angle (I might be wrong, of course).

In reality, we should never have any issue for any method occurring in 
any position inside a stuck lambda expression. Of course, if the method 
is the 'selected' part of some expression, that's standalone, so we do a 
full attr on it, so we are fine; but there are also many other cases 
where this is true:

* expression statements (Exec)
* non-poly conditionals
* RHS of a for-each loop
* ...

In all such cases the method is completely orthogonal from the context 
where it appears (the stuck lambda); so there should never be any need 
for doing things differently here (as the method as no relationship 
whatsoever with the inference context of the enclosing lambda).

The only places where I could see some issues are those where the method 
call appears in a return position in a lambda - in that case the method 
is indeed potentially related to an outer inference context, so I 
understand if we needed to do something special there. But, it seems 
like you recent patches already check a stuck lambda with the tier-1 
visitor, which should mean that all return expressions are NOT checked 
with the target-type visitor. So this shouldn't apply. No?

Maurizio

On 17/06/15 23:56, vicente.romero at oracle.com wrote:
> Changeset: 55a80eacfd55
> Author:    vromero
> Date:      2015-06-17 15:56 -0700
> URL:       http://hg.openjdk.java.net/tiered-attrib/dev/langtools/rev/55a80eacfd55
>
> do attribute the site of a field access expression inside a stuck lambda body
> any invocation inside a stuck lambda body is not fully attributed by default
> there are exceptions though, in particular the site of a field access expression
> can be fully attributed always
>
> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>