On Mon, 2007-01-29 at 22:26 +0000, Duncan Coutts wrote:
> On Mon, 2007-01-29 at 22:26 +0900, 向井 淳 wrote:
> > On 2007/01/29, at 21:55, Duncan Coutts wrote:
> > > Did you try the very latest darcs version of c2hs? Yesterday I added a
> > > couple patches that try to cope with more uses of __extension.
> >
> > Yes. I use the latest version of c2hs from darcs.
>
> Then sorry, my extensions fixes didn't help. You can try the technique
> of using cpp to make it go away:
>
> http://www.haskell.org/pipermail/c2hs/2006-May/000577.html
>
> Come to think of it, for the __extension__ token we could just drop them
> in the lexer... hmmm.
Try the attached patch, if it works for you, I'll apply it.
Duncan
New patches:
[Ignore __extension__ tokens in the lexer
Duncan Coutts <[EMAIL PROTECTED]>**20070129224758
Parsing them properly is hard yet the don't actually mean anything
except to not warn about the use of C99/GNUC extensions which we
have to be able to parse anyway, so just have the lexer allow but
ignore the keyword. ie treat it like whitespace :-)
] {
hunk ./c2hs/c/CLexer.x 345
- | GnuCExtTok -- `__extension__'
hunk ./c2hs/c/CLexer.x 527
- showsPrec _ (CTokGnuC GnuCExtTok _) = showString "__extension__"
hunk ./c2hs/c/CLexer.x 587
-idkwtok ('_':'_':'e':'x':'t':'e':'n':'s':'i':'o':'n':'_':'_':[]) =
- tok (CTokGnuC GnuCExtTok)
+idkwtok ('_':'_':'e':'x':'t':'e':'n':'s':'i':'o':'n':'_':'_':[]) = \_ -> lexToken
hunk ./c2hs/c/CParser.y 66
--- * We also recognize GNU C `__extension__' annotations (however, they are
--- not entered into the structure tree, but ignored). More specifically,
---
--- __extension__
---
--- may occur in a specifier list.
+-- * We don't need to recognize the GNU C `__extension__' annotations
+-- because the lexer accepts but discards that token.
hunk ./c2hs/c/CParser.y 203
-extension { CTokGnuC GnuCExtTok _ } -- special GNU C tokens
hunk ./c2hs/c/CParser.y 231
- | extension external_declaration { $2 }
hunk ./c2hs/c/CParser.y 384
--- * We allow the GNU C extension keyword before a declaration and GNU C
--- attribute annotations after declaration specifiers, but they are not
--- entered into the structure tree.
+-- * We allow the GNU C attribute annotations after declaration specifiers,
+-- but they are not entered into the structure tree.
hunk ./c2hs/c/CParser.y 533
--- * We allow the GNU C extension keyword before a declaration, but it is
--- not entered into the structure tree.
---
hunk ./c2hs/c/CParser.y 538
- | extension struct_declaration { $2 }
-
hunk ./c2hs/c/CParser.y 811
- | extension cast_expression { $2 }
}
Context:
[Doc fic for comments about context hook
Duncan Coutts <[EMAIL PROTECTED]>**20070128003019
They have 2 parameters, not 3.
Thanks to Debian's Arjan Oosting for the patch.
]
[Fix warning with newer versions of autoconf.
Jelmer Vernooij <[EMAIL PROTECTED]>**20060913122820]
[Support for *- out marshallers
Einar Karttunen <[email protected]>**20060902132122
Implement *- out marshallers that are a monadic
action but their return values are ignored. This
is very useful for converting error codes into
exceptions.
]
[Switch to new Data.Set API as required by GHC 6.6
Einar Karttunen <[email protected]>**20060902110758]
[Use precedence to eliminate an s/r in the C if-then-else syntax
Duncan Coutts <[EMAIL PROTECTED]>**20060529135534]
[Change handling of gnu __extension__ keyword
Duncan Coutts <[EMAIL PROTECTED]>**20060529133254
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.
]
[Try parsing C99 compound literals
Duncan Coutts <[EMAIL PROTECTED]>**20060529105014]
[Cancel previous patch installing the c2hs library
Manuel M T Chakravarty <[EMAIL PROTECTED]>**20060525181726]
[Fix typo
Jelmer Vernooij <[EMAIL PROTECTED]>**20060208004733]
[Install helper library for use by other packages
Jelmer Vernooij <[EMAIL PROTECTED]>**20060207224532]
[Teach c2hs about C style line pragmas for accurate source location info.
Duncan Coutts <[EMAIL PROTECTED]>**20060524174216]
[Use PreCST for CParser to avoid unnecessary module deps
Duncan Coutts <[EMAIL PROTECTED]>**20060523142434]
[Make the C parser test prog build again.
Duncan Coutts <[EMAIL PROTECTED]>**20060523135822
This program is useful for reproducing C parser errors
for when users send in their .i files.
Just run:
./parse foo.i
Build using:
ghc --make Main.hs -o parse ../i -i../../../base/general
-i../../../base/admin -i../../../base/errors
-i../../../base/state -i../../../base/syms -i../../state
]
[change handling of marshallers for dynamic function hooks
Udo Stenzel <[EMAIL PROTECTED]>**20060515142639]
[minor beautification
Udo Stenzel <[EMAIL PROTECTED]>**20060430215444]
[support fun hooks for FunPtrs inside structs
Udo Stenzel <[EMAIL PROTECTED]>**20060429235956
This is a bit hackish at times, as I cut-and-paste-coded a bit. Though
pending cleanup, it seems to work.
]
[improve translation of apath to identifier
Udo Stenzel <[EMAIL PROTECTED]>**20060429235900]
[allow call hooks for FunPtrs inside structures
Udo Stenzel <[EMAIL PROTECTED]>**20060429155023]
[darcs.haskell.org repo
Manuel M T Chakravarty <[EMAIL PROTECTED]>**20060514224852]
[calculate size of embedded arrays correctly
Udo Stenzel <[EMAIL PROTECTED]>**20060502231635]
[Adapt Setup.hs to Cabal in GHC 6.4.2
Manuel M T Chakravarty <[EMAIL PROTECTED]>**20060429012513
** WARNING: This will break the build on GHC 6.4.1 and earlier! **
On GHC 6.4.1 and earlier omit this patch or follow the instructions
in `Setup.hs'.
]
[Version 0.14.6 credits
Manuel M T Chakravarty <[EMAIL PROTECTED]>**20060429012404]
[tolerate variadic functions
Udo Stenzel <[EMAIL PROTECTED]>**20060423234358
This adds support for pointers to variadic functions in structs. They
cannot be called, but the rest of the struct is accessible without c2hs
bombing out.
]
[Allow escape sequences in the file name part of #line directives
Duncan Coutts <[EMAIL PROTECTED]>**20060406214715]
[enum define workaround example
Manuel M T Chakravarty <[EMAIL PROTECTED]>**20051219124518]
[TAG c2hs 0.14.5
Manuel M T Chakravarty <[EMAIL PROTECTED]>**20051212115038]
Patch bundle hash:
e913ce0dc34648e1d30f86a6d63d77c4e1d8bbcd
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
