A bunch of patches to the C parser. These need reviewing and testing. The first one seems to fix Ville's problem with parsing xmmintrin.h at least when still using c2hs -C-D__extension__= The second fixes it for me even without using -C-D__extension__= The reason was that the gramar was such that if it saw the __extension__ keyword at the beginning of an external decleration then it assumed that it could only be a data decleration and not a function decleration. This changes the __extension__ handling about quite a bit but the end result is that it allows __extension__ on functions too, which was the problem in Ville's example. This is the change that most needs testing since while it may fix this use of __extension__ is may break others where we were previously working ok. I guess we really need a regression test that tries loads of common system headers eg /usr/include/*.h . The last is mainly a tidy up. It hides a shift/reduce conflict. I checked that it doesn't change the parser's state transition tables. Still I'm not sure if using context-dependent precedence should be necessary here. Duncan Mon May 29 11:50:14 BST 2006 Duncan Coutts * Try parsing C99 compound literals Mon May 29 14:32:54 BST 2006 Duncan Coutts * Change handling of gnu __extension__ keyword GNU C allows __extension__ in various places we don't at the moment. This is a bit tricky to follow exactly without getting lots of shift/reduce conflicts. So what I've got here is a compromise. Sadly allowing __extension__ in expressions conflicts with it's use in declerations. So, instead of allowing __extension__ in any declaration I only allow it in an external decleration (top level). Fortunately I think that almost all uses of __extension__ in declarations are actually external declarations. So I think this is the right compromise. Mon May 29 14:55:34 BST 2006 Duncan Coutts * Use precedence to eliminate an s/r in the C if-then-else syntax