I am afraid that the fix of issue #140680 is causing serious problems. In short, the problem is that if the digest
matches, the "clean" conditions (most importantly: the "clean" parameter to the "updateFolder" method, classpath
mismatches and the "dirty" check [the latter two are checked inside the parseFiles method]) are ignored. These
conditions are supposed to compile all files in the given folder from scratch. The fact that these conditions are
ignored leads into incorrect error badges, and incorrect .class files. In the worst case, the .class files may not exist
at all (open a J2SE project with broken platform - this seems not to create the .class files at all. Correct the
platform - the .class files will not be generated.) Simplest reproducible case that I found is: have a J2SE project,
which contains a class (should not be opened in the editor, or at least should not be active in the editor) referencing
other class from a "standalone" .jar file ("standalone" means that no SourceForBinaryQuery will answer for it, so there
will be no sources attached to it). Remove the .jar from the project classpath - the error badges are not going to
appear. IDE restart won't fix it.

I would suggest to check the digest after checking the "clean" conditions in the parseFiles method, and (of course)
recompiling the source root if any of the "clean" conditions is met.

BTW: please use 'ensureAttributeValue(rootUrl, "digest", ..., **true**)' to verify the digest ("markDirty == true" will
ensure that if something goes very wrong during compilation (e.g. VM crash), next time the source root will be compiled
again).

Please either fix this or rollback/disable the digest optimalization ASAP. I personally do not think we should ship M2
with this problem.