As mentioned this is likely  a bit of precautionary restriction  
implemented way back, probably by John Maloney when at Apple. Any  
cCode stuff stops inlining.

Given the fairly small set of types (ab)used you might specialise to  
the form #declareCharStar: #foo etc and instead of catching the  
various forms of #var:declareC: etc in TMethod>recordDeclarations it  
would let them through. There'd be some ugly fixups elsewhere though,  
guaranteed.

It has to be said that the current state of the Slang translation is  
just insane. It was a fairly ugly hack to start with and has been  
mangled, folded, spindled and mutilated ever since. As an example  
gleaned whilst taking a quick look for a solution for you, consider
  - TMethod>inlineCaseStatementBranchesIn:localizingVars: and its use  
of #hasNoCCode and
  - CCodeGenerator>collectInlineList and its non-use of hasCCode but a  
mangled inline almost equivalent.

The textual inlining is terribly poorly factored and horribly hacked.  
It makes decisions based on nonsense metrics like how many nodes in a  
tree and are there more than an arbitrary magic number. The code  
probably won't work if you don't inline! At least it didn't a while  
back. The inlining/internalising of the bytecode loop is nasty,  
resulting in near duplicates of many methods for no very good reason.

My guess - and it is only a guess based on a few limited experiments  
ages ago - is that it would be smarter to drop the textual inlining  
completely, make the inline: pragma result in placement of a gcc  
__inline__ (or whatever the hell it is these days) on the function  
declaration line and let the compiler handle it.

Or better yet, completely rewrite the whole damn thing to do the job  
properly. Invent a better Slang. Add those bitfileds handling  
capabilities you need, and structures.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Fractured Idiom:- MONAGE A TROIS - I am three years old