SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

Mantis - Croquet
Viewing Issue Advanced Details
3299 Hedgehog major always 03-13-06 19:14 03-15-06 22:53
howardstearns  
 
normal  
confirmed  
open  
none    
none  
0003299: future messages compile as futureSend instead of futureDo
There places where an unused future in tail position of an if branch gets compiled as futureSend instead of futureDo:
       TAvatarUser>>pointerControl:redButton:
             - last line of redButton ifFalse:
             - last line of pointer selectedTarget ifNotNil:
       TXRay>resetSelected last line of the three itTrue: inside of ifNotNil: branches that end in future sends.

There are undoubtedly more. The ones cited cause the islands export and nameMap tables to grow as reported in 3297
     
These can be short-term fixed by inserting a nil no-op in the tail position of these branches, but the longer-term issue is fixing the #future compiler.
related to 0005695new  future in tail-position of block - core packages 
related to 0005696new  future in tail-position of block - demo packages 
related to 0005697new  future in tail-position of block - contrib packages: Minnesota 
related to 0005796new  internal future sends 
child of 0003298confirmed  futureSend futures never go away 

Notes
(0004459)
andreas   
03-14-06 02:35   
Interestingly, the bug is not as easy to fix as I first thought. Mainly because in a pattern of the form:
  block := [foo future bar].
it can't be decided at the point of compilation whether the return value of the block is being used or not, e.g., whether:
  block value. "no return needed"
  result := block value. "return value needed"
Unfortunately this also applies to seemingly trivial expressions like
  foo ifNotNil:[foo future bar].
where the compiler could (with additional analysis) determine the use beforehand (since the pattern is compiled inline).
(0004493)
andreas   
03-15-06 22:53   
Just confirming this bug as it may take a while to fix it.