Bug with embedded streams

[khatchad]

There seems to be a bug when a stream is used in a lambda expression that is fed to some intermediate operation. For example:

objects.stream().forEach(o1 -> objects.stream /* ... */).count();

The embedded stream doesn't even seem to have a creation instruction in the IR.

[khatchad]

There are two cases here:

1. As above, the tool will assign the same instruction to both stream creations because they appear on the same source line. This is due to Problem with Stream.getInstructionForCreation() #153.
2. The other case is where they are on different lines, as in:

objects.stream().forEach(o1 -> 
    objects.stream /* ... */).count();

Here, we don't run into #153 because of the line differences. However, since the instruction for the inner stream creation is missing from the IR, we fail.

[khatchad]

It's likely that the inner stream instruction is in a different IR. Note when I speak of IR above I meant the declaring method IR. The problem though is that there is only one AST. So, our tool thinks that there is a 1-1 and onto correspondence between the IR and the AST, which may not be the case.

[khatchad]

If this is true, it would seem we would always have an issue when a stream is declared inside of any lambda expression because of the IR differences.

[khatchad]

Basically what I think is happening here is that we are in a sense declaring a method inside of a method, which completely throws off the tool. Perhaps we can realize that we are dealing with either an AIC or a lambda and thus look up the correct IR.

[khatchad]

Filed wala/WALA#281. Could be related.

[khatchad]

Could also be related to #162.