PR# 17987 Changed application assertion monitoring not applied to library that uses application options

After initial compilation, changing application assertion monitoring to not 
check preconditions and supplier preconditions should disable monitoring of
these assertions in a library that specifies use_application_options="true".
It does not do so if the library is not precompiled and the system is
quick melted, frozen or finalized after the change.  This causes incorrect
assertion monitoring.

The same problem occurs with other options, such as "trace", though I didn't
include this in the test.  You may want to extend the test.

I think this needs to be fixed for 7.0.

Added test incr421 for this incrementality bug.

Run test incr421.

Fixed in rev#88022 of EiffelStudio 7.1 intermediate release.

I don't know if this can be implemented, but from my perspective the ideal
solution would be to keep read_only, allow both read_only and
use_application_options on a library and treat the library as read-only
for every compile where the application options did not change.
If the application options change, then the read-only indicator on a
library would be ignored for the next compile.

We found the reason for that regression. The new 7.0 compiler takes into account changes in the ECF and recompiles classes accordingly, 6.8 was not doing so. Now the reason it does not work in 7.0 is that when you change something in the ECF it will only apply to non-read-only entities. Unfortunately `base' was read-only and those changes are not taken into account.

Removing the `read-only' property of the library and the test would pass. We are currently debating the removal of `read-only' or at least making it an error if used in conjonction with `use_application_options', or simply make it false if `use_application_options' is set to True.

One more note:  test incr421 passes with 6.8 but fails with 7.0.87819, so
this is a regression rather than just a newly discovered bug that has been
there all along.

Another easy way to see that there is a bug is to instead specify
trace="true" on the first compile and trace="false" on the 2nd compile.
After the 2nd compile, tracing is still in effect on the library classes.

I don't agree.  Please take a closer look at the test.  For the first compile,
we have precondition="true" and supplier_precondition="true".  For the
second compile both of these are "false".  So preconditions should not be
monitored after the 2nd compile.  But they are.

You can easily confirm that this is indeed a bug by running the original test
and noting the output of the 2nd system execution.  Then delete the EIFGENs
directory, compile from scratch and run the system.  The output is different
than it was on the 2nd system execution.

The behavior is expected because the ECF states that EiffelBase uses the `application options' and the ECF of the application is requesting for precondition checking so they are always checked regardless of that `supplier_precondition' value.

I've changed the Ace for that test to not use `application options' for EiffelBase and the test passes. I haven't committed the change, I just want to confirm with you first.