Oops, I didn't run all the tests.

I think we'll want a more general solution here for any bit-type instead of just increasing the current set.

I'm not completely familiar with the current implementation but I think we'll want to drop the entry_int from builtin and add a new builtin_int_table or similar, then lazily create integer types as the symbols are resolved. You could probably investigate how the IntType builtin currently works and treat matching symbols in exactly the same way.

I'll let @andrewrk say more.

I'll try to take a look at the IntType.

Meh, as far as I can see that means I've to parse the variable name in Ir.cpp unless I it can be intercepted somewhere before.

Ok. I tried to hack it in, but now everything is broken. :D
Someone with more knowledge about where all the offsets and indices and whatnot are should probably do this.

I did fix the up to 128 case, so I'll push that in case anyone decides that's good enough for now.

I agree with @tiehuis. To solve #745 we do need to have a table of lazily generated int types, and we do need to parse the variable name just before looking it up in the primitive type table. Although we probably will pre-generate the common ones and keep references to them for convenience.

I'd be happy to prioritize this issue; I could knock it out pretty quickly since I have all the quirks memorized. Feel free to leave this PR up as motivation .

The self hosted compiler does not support integers yet :-)