On Tue Jan 10 23:05:02 2023 +0000, Zebediah Figura wrote:
In my understanding, the fundamental reason why we cannot propagate
from a temporary object is that temporary objects do not really exist. They are just a static kind of pointer. The only objects that exist really, AFAIU the language, are those represented by a uniform variable (which is later given a register type and number). All other object variables must be resolved at compilation time to a uniform object, or the program is to be rejected. From this point of view the thing that is meaningful to track is the underlying real uniform object, and once you adopt this point of view the bug just isn't there any more. Well... eh. From my perspective, there's nothing fundamentally wrong with saying that temporary objects exist. We have an obligation to get rid of them all by the time we're emitting SM1 or SM4, but that's just a restriction of the byte code. If we had a format that could deal with temporary objects—like, say, SM6, which we'll probably emit one of these days!—that whole axiom would go out the window.
Suspecting that you won't agree with me anyway, I guess you're the one
to decide, and I agree that solving the bug in the way I don't like is still better than not solving it at all. I'm sorry, I don't mean to frustrate by arguing. Plus, in general, if there's a disagreement I'd rather resolve it before putting my foot down—or, failing that, to at least understand the disagreement, and ideally reduce it down to a stylistic preference.
Alright, the possibility of temporary objects in SM6 argument is good enough.
If it wasn't for it I would be more inclined for Giovanni's approach, albeit, I suspect that adding the `!is_uniform` check on `copy_propagation_record_store()` would preempt some static references to be resolved.
I will revert to the previous approach.