ponder-lab/Optimize-Java-8-Streams-Refactoring

Bug with embedded streams

khatchad opened this issue · 6 comments

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.

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 #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.

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.

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.

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.

Filed wala/WALA#281. Could be related.

Could also be related to #162.