It was just an error-message difference.

I guess it's good that we have that since it was firing to tell us
that we were generating bad assembly.

Will take some more work to actually free thread-locals since we don't expose that
I'm surprised we didn't actually free any of that before!

It wasn't decreffing the previous value if there was one

- a lot of the tests were I removed the skip line are failing in the llvm tier - we will have to look at them later
- this does not enable the bjit yet

well, ones that aren't quite constant.  They can just register
their C static variables and then change them at will.

The _warnings module does this

It's bad that we need to do that right now, but it's not the job of
these tests to test that.

- Some missing refcounting annotations
- We would allocate before guarding, so if the guards failed we would
  leak those objects.
  - The code now treats this conservatively (like it should), which
    might result in more rewriter aborts.  I manually tried to fix
    the case that was hitting this for now.
- Small bug in the llvm-tier type specialization

- simple bug where when clearing the IC I forgot to clear
  the old list of gc references.
- keep gc references alive during the duration of the rewrite.
  There are some cases where the thing we are guarding on would
  normally get destroyed by the end of the operation.
  So make the ref an owned ref.  But at the end if we see
  that we hold the only reference to the object, abort the rewrite
  (since the guard could never pass in the future)

ie a commit that worked around our (previous) lack of refcounting.

I think technically only the globals are needed but I think this is
probably safer.

There's a FunctionMetadata* inbetween that doesn't get memory managed,
so the function just looks through that for now.

Or maybe it's just hacking it up some more.

Not very realistic but easy for testing

Use the CPython technique of swapping out the list contents for
the duration of the sort, since the compare functions can look at
the list.

This wasn't even being triggered by something that explicitly looked
at the list: the issue was that the comparison function invoked a
gc collection and the gc saw the half-mutated list.

ie if we do set.remove(k), we don't decrement k -- we decrement
whatever was in the set, which can be different.