Sometimes distanceFromObject return incorrect -1

[horasal]

TypeAnalysis uses distanceFromObject to determine which type can be the root. However, for some distances which are inherited from object, distanceFromObject still return -1.

The reason is that

• even though left and right are resolved, the type of them are not fully resolved. It means that their supertype, supertype ref(typedecl).... are still not resolved. When distanceFromObject reaches null ref, it returns -1.
• It seems that Object sometimes does not have a ref. When we create a new BaseType, we set its superType to Object but never set the reference.

[alexnask]

Is this really an error though?

If I recall correctly (and I'm pretty sure I do as I originally wrote typeAnalysis), distanceFromObject returning -1 (or findCommonRoot returning null) does not mean we have no match but rather an indication that we EITHER don't have enough info to make a call or have no match.

It is the caller's responsibility to make sure everything is resolved if he wishes to be sure there is no common root.

This is probably not true on most call sites, which must be causing unnecessary wholeAgain's and perhaps even LOOP's, significantly hurting compile times.

This is a common thread in multiple places in rock (mainly thinking about the scoring system and most other typesystem related activities).

It would probably be better design to return some kind of result cover that holds an error flag and the final result (same with scores/matches, -1 doesn't always give us true information).

As for the Object BaseTypes assigned directly directly, they should be resolved at some point, giving us their ref.

If they are never resolved and are actually needed in the middle end (as opposed to some Int creations in anonymous struct literals and things of that nature that are "just" used by the backend), this is indeed a bug.