the problems (errors/warnings/infos) that were generated in the last incremental compilation, be it successful or not. See previousProblemsFromSuccessfulCompilation for an explanation of why these problems are important for the bloop compilation.

Returns the problems (infos/warnings) that were generated in the last successful incremental compilation. These problems are material for the correct handling of compiler reporters since they might be stateful with the clients (e.g. BSP reporter).

Change the paths of the class files inside the analysis.

As compiler isolation requires every process to write to an independent classes directory, while still sourcing the previous class files from a read-only classes directory, this method has to ensure that the next user of this analysis sees that all products come from the same directory, which is the new classes directory we've written to.

Up in the bloop call stack, we make sure that we spawn a process that copies all class files from the read-only classes directory to the new classes directory so that the new paths in the analysis exist in the file system.

Update the previous result with the most recent classpath hashes.

The incremental compiler has two mechanisms to ascertain if it has to recompile code or can skip recompilation (what it's traditionally called as a no-op compile). The first phase checks if classpath hashes are the same. If they are, it's a no-op compile, if they are not then it passes to the second phase which does an expensive classpath computation to better decide if a recompilation is needed.

This last step can be expensive when there are lots of projects in a build and even more so when these projects produce no-op compiles. This method makes sure we update the classpath hash if Zinc finds a change in the classpath and still decides it's a no-op compile. This prevents subsequent no-op compiles from paying the price for the same expensive classpath check.