PR# 18164 Unnecessary degree 3 processing after touching class

In a particular system (isolated from a real-world project), simply touching
the file containing a particular class, without making any changes to it,
and then compiling causes degree 3 (and 2 and 1) to be done for a number of
classes other than the one that was touched.

Extract bug.tar.  Change to "bug" directory.
Do "ec -config bug.ecf -verbose".  Compiles normally.
Do "touch source/reticle_view.e".
Do "ec -config bug.ecf -verbose" again.  Does degrees 3 (and 2 and 1)
on a number of classes other than the one that was touched.

OK, I reproduced it on a simple example (11 classes, 150 lines total).

To reproduce:

Unpack newest_bug.tar.bz2.
Compile: ec -config bug.ecf -verbose
Touch file:  touch source/reticle_view_element.e
Compile again: ec -config bug.ecf -verbose

On the second compile, compiler does degree 3 for some additional classes
(besides RETICLE_VIEW_ELEMENT).  Definitely related to use of anchored types.

Well, I didn't get the example particularly small - about 525 classes and
100000 lines.  But it depends only on EiffelBase.

To reproduce:

Unpack attached archive.
Compile:  ec -config bug.ecf
touch source/delta/packing/reticle_view_element.e
Compile again: ec -config bug.ecf

Compiler does degree 3 on some additional classes, besides RETICLE_VIEW_ELEMENT.
It is definitely related to anchored types, based on my experiments.

OK, thanks for the status update.  For my current example:

1. full_class_checking = False  (so that's not the problem here)
2. We do not use any qualified anchored types as far as I know, only
   normal anchored types.

I will try to reproduce on a reasonable size example and if I do, I will
upload it here so that you have a test case when your improved incrementality
code is ready.

This is correct, our compiler still performs too many recompilation but this is not easy to fix unfortunately. Each case is being different but it is mainly for two reasons:
1 - full class checking is enabled
2 - some anchored types especially qualified ones

We clearly haven't done enough to improve #1. As for #2, it is a rather difficult thing to do.

We are working in designing a new incremental mechanism that will avoid some of the pitfall of the current one which was designed at a time where many of the new aspects of Eiffel were not present.

Although the test cases I reported in this bug are indeed fixed in 7.3
(no extra unnecessary degree 3 processing), the much larger system from which
these examples were derived still exhibits the problem.  That is, in this
larger system touching a class still causes degree 3 processing on many
classes.  In this case, touching the original class (source/reticle_view.e)
causes degree 3 to be done on 129 classes.  Touching a different class
(source/reticle_view_element.e) causes degree 3 to be done on 482 classes.

Perhaps I should give you the full system, but it is a *lot* of classes.

Thanks for fixing this.  It will be useful on Solaris SPARC where compilations
are not that fast.

Fixed in rev#92411 for the 7.3 release.

We finally managed to fix the problem. We are running eweasel tests to confirm. The issue was that whenever a class had some anchors in signatures of features, we would always recompile its clients even if nothing has changed.

In the process, we have also fixed an issue with {TMP_AST_SERVER}.body_item and {TMP_AST_SERVER}.body_force that would cause the compiler to crash in some incremental recompilation.

Confirm that in 6.6.8.3873, it is the same behavior.

Here is an even more simplified test case.  It contains only 19 classes
with a total of 283 lines.  To reproduce, follow the same directions given in
the original bug report.

Attachments for problem report #18164