AbstractImageBuilder and ICompilerFactory not passing a CompilationProgress

[mickaelistria]

From an implementation of compiler (either with ECJ or Javac as backend), it's not possible to check the cancellation status directly because no CompilationProgress is passed to the compiler. It seems possible to easily-ish implementation such a CompilationProgress in AbstractImageBuilder delegating to BuildNotifier, and to improve the ICompilerFactory interface so it forwards such CompilationProgress object.

[mickaelistria]

cc @testforstephen

[jukzi]

relates to #3317
The Compiler uses to call org.eclipse.jdt.internal.core.builder.BuildNotifier.checkCancelWithinCompiler()

[mickaelistria]

Actually, even that last call as part of acceptResult is not usually the one that cancel the compilation (AbstractImageBuilder orchestrates the compilation, but the compiler doesn't really know of whether it's called by a builder or some other way to fully rely on this assumption). The operation that is most often aborting the build is the one from NameEnvironment.findClass(). So in most cases, the name lookup is responsible for cancellation of the compiler, which seems

[jukzi]

Compilation of a single source takes usually only milliseconds. Why would you like to check for cancel more often?

[mickaelistria]

Because not all cases are Compilation of a single source. Import jdt.core in a fresh workspace and you get more than a thousand files built together. And this takes about a dozen of seconds with ECJ.

[jukzi]

Sure, i have projects that take minutes to build, but i have no problem in canceling them (despite APT) - feels like NameEnvironment.findClass() is called often enough, especially since canceling wait at least 1second any way (see BuildNotifier.millisecondsBeforeCancelAutoBuild)