[Swift-devel] Creating 0.94 RC with fixes for STOMP

Mihael Hategan hategan at mcs.anl.gov
Wed Nov 21 11:40:15 CST 2012


On Wed, 2012-11-21 at 08:45 -0600, Michael Wilde wrote:
[...]
> 
> Mihael - David is planning to create a new 0.94 release candidate, and
> was deliberating how much of trunk to include. (My preference would be
> to start the RC with all of current trunk).  Can you two discuss what
> to include in the RC, and then David will create the release and start
> testing it?

Now that we're at it, I was working yesterday on "fixing" array closing
issues. In particular cases like 
int[] a;
scope1 {
   scope2 {
     a[i1] = v1;
     f(a);
   }
   scope3 {
     a[i2] = v2;
   }
}

and variations.

The idea is that:
- closing does not need to happen in the declaration scope, but can
happen in the place where a[] is last written to (in the cases where
"last written to" happens in multiple places, Ben's partial closing will
still apply, but, again, not necessarily in the declaration scope). This
make a lot of cases that would deadlock before work now.
- the compiler determines either that:
  1. closing can happen without a deadlock and issues appropriate
statements to do so
  2. there is no way to do it without a deadlock, in which case compiler
issues a clear error message stating so.

It's not trivial because I need to keep track of both read and write
access to variables, and also their respective locations within the
scope tree, as well as how iterations and if conditions may affect
things. That combined with the general crappiness of the exiting
compiler code. But with a bit of work, I think it's doable and it will
go miles towards reducing unexpected and perplexing behavior in complex
scripts.

So I have to teach the kids about magnetic induction right now, but it's
about the last thing I have to do for the week, so this might be a good
time to finally put this issue to rest.

As usual there are advantages and disadvantages to including this in the
upcoming release, so...

Mihael




More information about the Swift-devel mailing list