PR# 19669 Runtime [?] seeing wrong object types

Reposted here because the original report posted on 2020/06/04 disappeared.  I also removed references to external library and hopefully attached a working zip file.

This started as an academic exercise to develop an Eiffel-only solution for big numbers.  My jj_big_numbers library depends on another set of classes called jj_naturals.  Cluster jj_naturals contains a set of classes which override the NATURAL_xx_REF classes.  The idea was to get a common ancestor to all the natural classes, setting between NUMERIC and the NATURAL_xx classes.  
NUMERIC
     JJ_NATURAL
          NATURAL_8_REF      -- my class
               NATURAL_8
          NATURAL_16_REF    -- my class
               NATURAL_16
          NATURAL_32_REF    -- my class
               NATURAL_32
          NATURAL_64_REF    -- my class
               NATURAL_64
JJ_NATURAL adds some bit operations and convenience features and allowed for generic classes that operate on NATURALs.  (You can look at https://github.com/boxer41a/jj_sha for a project that seems to work just fine when using these classes.)

Class JJ_BIG_NATURAL [G -> JJ_NATURAL] tests that assumption, but seems to be failing in ways that I cannot understand.  So,
1)  Can the above inheritance structure work?  I know that sometimes things will compile but not work as a layman might think.  (e.g. a few years ago I tried to modify ANY by adding attributes which seemed okay but failed during runs)
2)  What is the cost of the above?  Is it slower?  How much?

Run autotest on BIG_NATURAL_8_TESTS.  I am only concerned about two failing tests:  1) `is_negative' and 2) `from_array'.  I think my generics and override classes confuse the runtime...

Under demo run big_natural_demo and run autotest.

In BIG_NATURAL_TESTS see feature `run_all'.  It describes the failures in `set_with_array' and `is_negative'.
Notice that `is_negative' follows same format as `is_zero' which does not fail.  ??

Questions: 
4) Test `is_negative' fails on my precondition "target_closed".  Why?  Other tests that follow the same pattern work just fine?
5) Test `set_with_array' gives incorrect results.  In fact, feature `set_with_array' from JJ_BIG_NATURAL shows funny results when paused in the debugger.  After executing the line "d := a_array [i] ",  `d' shows a different value than what the debugger shows to be in `a_array [i]'  ???

I don't know if y'all review these old posts...

I decided to revisit this problem.  I removed the modifications to NATURAL (i.e. no overrides) and also tried with version 20.05 (with updated alias syntax).  I get the same errors, so these problems have nothing to do with my "modifications of basic classes".

So, if you have time I would really appreciate someone trying to run autotest on feature `is_negative' (using 19.05) and see what I am missing.

I appreciate the work EiffelSoftware does to provide EiffelStudio.  Thanks again.
jjj

I saw that answer.  I also downloaded the files which ISE managed to "run".  In that modified project, the classes were converted to version 20 point something and my offending classes were removed.  So, of course it ran with no errors.

Am I to understand that no one there actually ran my files or tried to duplicate my error?

What is odd, I used these same classes in a library that produces SHA digests and it seems to work fine.

"Adding a feature to such a class usually involves changes to the compiler. This explains why not everything works as expected."  Okay, but is it not worth checking to see if that is the case?  Why does it work for most of the tests but not that simple one (which is almost identical to others which work just fine?

Give me one last answer and I will drop this.

jjj

This report is a duplicate of https://support.eiffel.com/report_detail/19648

I have the feeling you did not read the last message there.
Side note: you can display previous closed reports by checking the related "status" checkbox and press Search, from https://support.eiffel.com/reports. To see all reports (for any status), https://support.eiffel.com/reports?status=0&status=1&status=2&status=3&status=4&status=5 

However, the answer you got from Alexander on previous report https://support.eiffel.com/report_detail/19648 remains the same.
Here is a copy/paste:

Basic classes are handled by the compiler differently from non-basic ones. In other words, code generated for these classes is different. Adding a feature to such a class usually involves changes to the compiler. This explains why not everything works as expected. In theory, it might be possible to change code generation (including both classic and .NET) and to support arbitrary code in basic classes. However, this functionality is rather niche
....
Output truncated, Click download to get the full message

Anyone tried with version 19.05 to reproduce my errors?  This was resent in September.

First, let me apologize for not seeing the filter buttons at the top of the page.  I now see the response.  I suspected that modifying the basic types may be causing problems.  Too bad, because it allowed me to test [manually] with 8-bit numbers and easily change an implementation to 32- or 64-bit numbers (and I thought a common ancestor for all the natural numbers was more elegant, even if the work-arounds were not.)  I guess I can put the additional functionality in a utilities class.

Second, sorry my email changed.  I tried to update it but I never got an email response with an activation-code.  Maybe I can call.

Third, EiffelStudio 20.05 on my iMac keeps crashing, so I am still using the 19.05 version.

Fourth, I attached  a new archive_4.zip file which I believe has no externals and simplified ecf file;  It does (and must) use  the override files.

Now to the original problem, for what it is worth:
1)  The test routine 'is_negative' still violates the precondition "target_closed" in the call t
....
Output truncated, Click download to get the full message

By the way, do you confirm you get the answer from the support team by email ?
Such email should be sent to 	jimmy.johnson@windstream.net 

Apart from that, I've just tried to run the autotest cases, for the jj_naturals_demo.ecf and nothing bad happened.
I also took time to update to EiffelStudio 20.05 

See the output, and the archive for 20.05

I had to modify the various .ecf to test, and then I was not able to compile the jj_big_numbers/demo project due to missing classes (MPZ_FUNCTIONS, ...).

For info, the previous report did not disappeared, see https://support.eiffel.com/report_detail/19648  (the status was set to "won't fix", and by default in the reports list, the "closed" and "won't fix" report was not displayed. You can however display them by checking the related checkbox and press Filter).
I also confirm your archive is valid.

But I fear the answer you got on previous report https://support.eiffel.com/report_detail/19648 remains the same.

Attachments for problem report #19669