this gets triggered by M2Crypto which sets an error but returns None.
previously we throw the error in the non rewriter path and ignored it in the rewriter.
this makes it now identical and mote like cpython does it (only looks at the return value)

the fixed blocksize of our region allocator was too small for very large actions
fix this by using the more powerful llvm::BumpPtrAllocator which handles allocation larger than the slab size

previously we checked if NDEBUG was defiend but this caused problems with extensions which modified this define

interpreter: mark created_closure as live variable inside yields

without this we would never traverse the variable and the GC would therefore be unable to destroy the generator

The issue with django was that it called object.__dict__.__get__(unicode),
which would convert object to dict-backed, and then our shutdown logic doesn't
support that case.

The shutdown logic still doesn't support that case, and there are other ways
to convert object's __dict__ to being dict-backed, so this commit isn't a full
solution, but it seems like something we should do anyway.

Try to reduce JIT time for the LLVM tier

I was worried we were in trouble since we don't always pass an owned
reference to any arguments filled via defaults, but for Python functions
this is fine since we will end up creating our own reference to it.
For builtin functions, we disallow changing defaults.

Not sure if it matters, but there are some cases that our
refcounter will add decrefs earlier than CPython would, if it
can prove that the variable won't end up getting used.

One example is in:

for i in foo():
  break

The iterator object (`iter(foo())`) will not get used after the first
call to next().  So our system will put the decref at the top of the loop.
CPython will do the decref after the loop exits, like normal.

and switch the llvm tier to use them instead of its own analysis

Apparently they are slowing down the irgen phase in debug mode quite a bit,
since a lot of the time is dominated by InternedString hashtables.

I think this is the main source of our jit-time regression.

This time, structure it a different way,  This does a better job of
highlighting the JIT-time regression from the refcounting branch.

Enable the gcc build

The release CI builds are failing since they run the extra tests

Fix usage of undef variables

I think I had gotten confused and mixed up "undefined variables" (Python
variables which hadn't gotten set) and "undefined values" (results of
expressions that the JIT knows will throw, or otherwise can't evaluate).

For undefined *variables*, we represent them using None, since they can
still have refcount operations done on them.

For undefined *values* (or results), we can use llvm's undefValues, since
they should never be touched.

I ended up running "make update_section_ordering" multiple times since it seemed to help.
Or maybe things are just very random and then I picked one that happened to benchmark well.

This should fix the bad behavior we had where setGlobal would only get rewritten
by having its call to setattr() get inlined, and having setattr() then think it
was being called directly.  This was both brittle (only worked on release builds)
and incorrect (there were checks that happened before calling into setattr, which
needed to be emitted as guards).

I had hacked in an attribute((always_inline)) to at least deal with the brittleness,
but this should be a fix for real.  And let us reenable the gcc builds.

Otherwise they can end up seeing the return address of their caller

Fix the last two reffail tests

At least what I added here is what CPython does.

But still some in test/integration

Undo a bunch of Pyston changes to cpython code

copy CPython sys.getsizeof implementation with some Pyston changes

Bitset iteration micro optimize

This just copy the CPython implementation, so some NumPy tests could pass.
But most of types in Pyston didn't implement '__sizeof__' attribute yet.

Haven't been able to test them all extensively but I tried
to only pick things refcount-related.

Another run-arbitrary-code-during-unwinding issue

The part that tests that certain dicts compare a given way.  We don't
have consistent dict comparisons yet (#1135)