mainland/language-c-quote

language-c-quote's Issues

Block parsing bug

The follow errors with: "parse error on `CGRect'".

[self.codeText addKeyboardPanningWithActionHandler:^(CGRect keyboardFrameInView) {
            /*
             */
        }];

I think it is just a missing case.

C-style comments in cunit declarations

Hi. The XXX comment in the following code triggers compiler error:

someGenerator = 
        let
        ...
        in
        [cunit|
            $edecls:(cdefs serverRpcReq)
            $edecls:(cdefs serverRpcRes)

            /* Some comment */
            struct $id:srv_name {
                /* Input arena buffer */
                nk_uint8_t *inp_arena_buf;
                nk_size_t inp_arena_buf_sz;
            };

            /* XXX */
            struct $id:ops_name {
                $sdecls:(map methodSDecl methods)
            };
        |]

The error looks like the following:

.../src/Compile/Server2.hs:320:17:
    .../src/Compile/Server2.hs:344:13:
    parse error on `/* XXX */

I'm using 0.11.7 version. According to the Changelog, later versions also should be affected.

Support for Obj-C generics and type annotations

Are generics and type annotations something you are thinking of adding to this package for Obj-C?

For example, it's now legal to do something like NSDictionary<ClassA*,ClassB*>* in Obj-C to annotate that the NSDictionary is parametrized over ClassA and ClassB. From my cursory look at the code it appears this is not supported.

Objective-C anti-quotations for interface decls broken

I know, I'm late to the party, but I just noticed that the changes between version 0.9 and 0.10.0 made to Objective-C anti-quotations are broken. Specifically, language-c-inline has got a binding like this

iface = [cunit| 
  @interface $id:prefixedClassName : NSObject

  $ifdecls:propertyDecls
  $ifdecls:updateMethodDecls
  $ifdecls:ifaceDecls

  @end
|]

Unfortunately, this pretty prints without expanding the anti-quotations; so, I get

@interface Particle : NSObject 
$ifdecls:propertyDecls
$ifdecls:updateMethodDecls
$ifdecls:ifaceDecls
@end

From what I can see, it must have been the changes between 1627e25 and fa98219 (which clang really doesn't like).

Lexer error after pragma in quasi-quote

I'm trying to use quasi-quotes to generate OpenMP. But I get a lexer error in some cases. Here's a small test case:

[cstm| #pragma omp sections
       {
         #pragma omp section
         a = 1;
        }|]

I get the following error:

    lexer error on 
                  a = 1;
                  } 

Support for lambda-expressions

Hi,
would it be possible to add support for lambda-expressions from C++11? It is needed for the accelerate-cuda package in order to work on Windows (AccelerateHS/accelerate#234) or take advatange of the new runtime compilation library (AccelerateHS/accelerate#258).
Currently accelerate-cuda uses expression statements that are non-portable GNU extension. It can be and needs to be replaced with lambda-expressions. I did a quick hack (mwu-tow/language-c-quote@e670cfd) to pretty printer, so the expression statements are translated to lambda-expressions — and it was confirmed to solve the issues.

Ideally, the lambda-expressions support should be added to language-c-quote — that includes defining new AST structures, parsing and code pretty printing.
However, I'm not sure how it fits in. Lambdas are C++ feature, they are not part of C language. Should they only work in CUDA extensions mode? Is this an acceptable extension fitting the purpose of this package?

Please, let me know what is your view on this issue and how we should proceed from here.

Objective-C Property parsing bug

Objective-C's parser seems to be only able to parse 1 property "annotation" instead of a list.

This parsers correctly:

@property (strong) typename RACSignal *verticalPadding;

This does not:

@property (nonatomic, strong, readonly) typename RACSignal *verticalPadding;

AppDelegate.hs:48:52: AppDelegate.hs:52:20:
    parse error on `,'

Parse and print '#line' directives

It would be nice to be able to manipulate #line directives with language-c-quote. I'm particularly interested in setting source locations for statements.

I can imagine two approaches to implement this:

1. Parse #line directives and set SrcLocs accordingly. When pretty-printing, if an element of the AST has a Loc, use the file and line from its starting Pos to emit a #line directive. As an optimization, it might be nice to suppress any #line directive with the same filename as the previous directive, and where the difference in line numbers between the two Locs is the same as the number of lines pretty-printed since the last #line. If you don't want these directives you can rewrite all SrcLocs to NoLoc before pretty-printing.
2. Add a Line constructor to Stm, like Pragma.

Which would you prefer?

Empty statement required after comments

Hi Geoff,
I was building Ziria today and found two places where the new comments parser broke existing code.
pchickey/Ziria@e2bb98e
They were easy for me to fix because I was already familiar with the changes to comments. However, I suspect these bugs would be quite tricky otherwise.

src/Codegen/CgOpt.hs:714:39:
    src/Codegen/CgOpt.hs:723:30:
    parse error on `EOF'

src/Codegen/CgSetupThreads.hs:57:32:
    src/Codegen/CgSetupThreads.hs:63:33:
    parse error on `$stms:(my_sizes_inits (zip [0..] buf_tys))'

Is there any way around the empty statement restriction? If not, is there a better way to report these errors?

Pat

Support for syb-0.5.1

Could you release the relevant upper bound? Stackage issue commercialhaskell/stackage#615

Build error

http://hydra.cryp.to/build/202901/nixlog/1/raw

Semantics of type qualifiers near antiquotation is different from semantics of typedef

intPtr = [cty| int * |]
addConst t = [cty| const $ty:t |]
result = addConst intPtr

The result is supposed to be int * const, but it is const int *.

UPD.

All I want is equational reasoning, for example (in pseudo-C):

x = int *
const $x == const (int *)

when current implementation gives:

const $x == (const int) *

relax syb constrain to >= 0.3 && < 0.5

syb >= 0.3 && < 0.5 where before it was >= 0.3 && < 0.4, seems to work for me.

awesome lib, i'm using a wee script that @maxpow4h wrote to auto generate some blas and lapack bindings a bit more sanely than i'd otherwise be able to

Cannot create block consisting of a single statements antiquote

When creating a block whose only member is a statements (plural) antiquote, the antiquote is not processed. For example:

[cstm|if (!initialized) { $stms:init_stms }|]

No obvious way to generate macro code -- not even through $esc:(... :: String)

It doesn't seem possible at all to generate C code referring to macro calls.

Not even through the supposedly almighty dirty escape hatch:

[citems|
struct cap *cap;
$esc:("list_for_each (cap, list, &acl->list)")
        printf ("cap: %s\n", cap->name);
|]

yields:

parse error on `$esc:("list_for_each (cap, list, &acl->list)")'

Double negation

Not sure if this problem is in language-c-quote itself or mainland-pretty, but no parenthesis get placed around the argument to a negation, which so negate (negate x) turns into --x and is incorrect.

{-# LANGUAGE QuasiQuotes #-}

import Language.C
import Language.C.Quote.CUDA
import Text.PrettyPrint.Mainland

neg :: Exp -> Exp
neg x = [cexp| ( - ($exp:x) ) |]

main :: IO ()
main =
  print $ ppr $ neg (neg [cexp| 42 |])

ghci> :main
--42

language-c-quote-0.11.3 does not compile with alex 3.1.5

Citing from http://hydra.cryp.to/build/1392350/log/raw:

Language/C/Parser/Lexer.x:508:38:
    Not in scope: ‘ord’
    Perhaps you meant one of these:
      ‘or’ (imported from Prelude), ‘odd’ (imported from Prelude),
      ‘ord#’ (imported from GHC.Exts)

Language/C/Parser/Lexer.x:508:46:
    Not in scope: ‘ord’
    Perhaps you meant one of these:
      ‘or’ (imported from Prelude), ‘odd’ (imported from Prelude),
      ‘ord#’ (imported from GHC.Exts)

Language/C/Parser/Lexer.x:512:38:
    Not in scope: ‘ord’
    Perhaps you meant one of these:
      ‘or’ (imported from Prelude), ‘odd’ (imported from Prelude),
      ‘ord#’ (imported from GHC.Exts)

Language/C/Parser/Lexer.x:512:46:
    Not in scope: ‘ord’
    Perhaps you meant one of these:
      ‘or’ (imported from Prelude), ‘odd’ (imported from Prelude),
      ‘ord#’ (imported from GHC.Exts)

Showing Syntax Tree

Hi,

Thanks for the great library. In using language-c-quote, I've found it useful to parse C to see what syntax tree is generated to figure out how to generate an appropriate syntax tree myself. However, this is difficult to do, since you don't have default Show instances on your Syntax datatypes.

As a hack, I've commented out the show instances in Pretty.hs and derived Show on the Syntax.hs datatypes. Essentially, I'm advocating decomposing PrettyShow with Show.

I could send a patch, but you might want to refactor things differently, so I wanted to open an issue first.

Use GitHub Actions for testing

Travis is going down the tubes, so this repository should probably use GA instead.

$id: antiquoter should expect an `Id`, not a `String`

I think it is inconsistent that in $id:x, x must be of type String. To be uniform with the other anti-quotation forms, x ought to be of type Id.

Then, in addition, we ought to have $idname:x, where x is of type Name (this is TH's Name type).

pretty-print `AntiTypeDecl`

If I parse a piece of C code consisting of $ty:(something), then there're chances that the AST has AntiTypeDecl "something" loc in it. But I don't see a way to ppr it. It leads to non-termination because the only base case in the recursive pprDecl function is `DeclRoot loc'. Though I'm not clear what's the rationale behind it, printing out the antiquotation as-is seems to be a natural treatment. If there are reasons indeed, it'd be better documented, and provide another function that does it. Please correct me if I'm mistaken. Thanks.

Request: antiquoter for [TypeQual]

This is useful when generating OpenCL kernels and you want to indicate the address space of a pointer.

Nested statement quotations fail

In order to work around #32 I wrote this:

return [cstm| #pragma omp parallel sections
              {
                $stm:( [cstm| #pragma omp section
                              $stm:s1 \|\]
                      )
                } |]

But that code produces the following error:

    Exception when trying to run compile-time code:
      Language.Haskell.Meta.Syntax.Translate.toExp: not implemented: QuasiQuote "cstm" " #pragma omp section\n                                $stm:s1 "
      Code: Language.Haskell.TH.Quote.quoteExp
              cstm
              " #pragma omp parallel sections\
              \                {\
              \                  $stm:( [cstm| #pragma omp section\
              \                                $stm:s1 \\|\\]\
              \                        )\
              \                  } "

No nested quotations examples

I badly want nested quotations, but still I have no luck using \|\] from the README. Could you please clarify the status of this feature?

language-c-quote v.0.3.1.2 build hangs

Hi Geoffrey.

I made a script to install Haskell from scratch on Linux Debian systems. The script seems for now solid.

While installing language-c-quote v.0.3.1.2, cabal hangs at:
[13 of 15] Compiling Language.C.Smart ( Language/C/Smart.hs, dist/build/Language/C/Smart.o )

With a direct "cabal build --verbose=3", the process hangs after the line
"Loading package exception-mtl-0.3.0.2 ... linking ... done.".

The last ghc message was:
'/usr/bin/gcc' '-fno-stack-protector' '-L/home/chrandr/prj/tools/haskell_repository/ghc-7.4.1/usr/lib/ghc-7.4.1/unix-2.5.1.0' '--print-file-name' 'libdl.so'

The script can be found at: https://github.com/chrand/haskell_install
The set of installed packages are the ones brought in by the script (fresh install).

Thanks,

Christian

Missing antiquotations for initializers

Once one gets to generating array/structure initializers, the picture quickly gets ugly, forcing one to get down to the AST level and build an array of helper functions increasing in sophistication.

Having an antiquoter for designated/undesignated initializers for arrays and structures would have helped a lot.

Bug parsing some initializers

Parsing the following errors with: "expected ';' but got `='"

- (int)compile {
    NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
  }

[BUG] Comments at the top of a function definition break

Here's a simple module illustrating the trouble.

{-# LANGUAGE QuasiQuotes #-}

module Test where

import qualified Language.C.Syntax as CS
import qualified Language.C.Quote.C as CQ

test :: [CS.Definition]
test = [CQ.cunit|
  int f() {
    // Breaking comment..
    int x;
  }
  |]

Here's my GHC version and attempt at compiling this module.

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.2
$ ghc Test.hs 
[1 of 1] Compiling Test             ( Test.hs, Test.o )

Test.hs:9:18: Test.hs:12:5:
    parse error on `int'

Putting variable declaration before the comment seems to work as intended.

build-tools is deprecated

The build-tools stanza in .cabal files has been deprecated and should be replaced with build-tool-depends, perhaps guarded by an if-statement?

Generating Comments

It would be really nice to have a way to generate comments from the quasi-quoter. Have you thought much about how this might be implemented? As a first pass, having them at the statement block level would take care of my needs, but I'm sure that they could be useful at other levels of the AST as well :)

Bad char literal output

λ> putDocLn (ppr [cexp| $char:('\0') |])
'\NUL'

GCC:

error: unknown escape sequence: '\N' [-Werror]
error: multi-character character constant [-Werror=multichar]
error: overflow in implicit constant conversion [-Werror=overflow]

Negated negative constants do not correctly pretty-print.

Negated negative constants are not correctly printed.

For example, this:

[cexp|-$int:(-42)|]

is pretty-printed as --42.

Add to Stackage

The language-c-quote package seems to exist in an old-ish LTS and a nightly snapshot from December:

https://www.stackage.org/package/language-c-quote

Since this package is a really wonderful way to generate C ASTs, it would be nice if it was included in new nightly and LTS snapshots. Was there a reason it was removed? I don't much know how Stackage is managed.

Macros should be preserved

Macros in the input should be preserved in the output.

Ideally, they would be evaluated for type names (i.e. the BOOL macro), but that is a problem for later.

Build failure due to conflicting <>

I got this while kicking off the latest LTS Haskell build (11.4):

[ 6 of 16] Compiling Language.C.Parser.Parser ( dist/build/Language/C/Parser/Parser.hs, dist/build/Language/C/Parser/Parser.o )

dist/build/Language/C/Parser/Parser.hs:12200:19: error:
    Ambiguous occurrence ‘<>’
    It could refer to either ‘Data.Monoid.<>’,
                             imported from ‘Data.Monoid’ at dist/build/Language/C/Parser/Parser.hs:27:1-18
                          or ‘Text.PrettyPrint.Mainland.<>’,
                             imported from ‘Text.PrettyPrint.Mainland’ at dist/build/Language/C/Parser/Parser.hs:28:1-32
                             (and originally defined in ‘Data.Semigroup’)
      |
12200 |         ppr ident <> if null ps then empty else angles (commasep (map ppr ps))
      |                   ^^

dist/build/Language/C/Parser/Parser.hs:12208:49: error:
    Ambiguous occurrence ‘<>’
    It could refer to either ‘Data.Monoid.<>’,
                             imported from ‘Data.Monoid’ at dist/build/Language/C/Parser/Parser.hs:27:1-18
                          or ‘Text.PrettyPrint.Mainland.<>’,
                             imported from ‘Text.PrettyPrint.Mainland’ at dist/build/Language/C/Parser/Parser.hs:28:1-32
                             (and originally defined in ‘Data.Semigroup’)
      |
12208 |     ppr (TStypeofExp e _)   = text "__typeof__" <> parens (ppr e)
      |                                                 ^^

Parser rejects C99 complex types

I can't get C99 complex numbers to work:

[cty| float complex |]

silently ignores the complex keyword.

[cty| float _Complex |]

results in a parser error:

    bad type: float _Complex

However, the parser accepts

[cty| _Complex |]

but that is not a C99 type.

Are complex number types broken or am I missing something?

AntiQuote for Initializer

Hi, would it be possible to have an antiquote specifier for the Initializer type? There doesn't seem to be one, and it would be quite useful.

Support for "case start...end:" syntax

case start...end: is a GNU extension, but is well-supported by both GCC and Clang.

I would like to try to implement this feature, and I'd appreciate any pointers you might have about what all needs to be updated in order to support it.

Antiquoters for Obj-C ObjCIfaceDecl

It would be useful if the anti quoters were available for ObjCIfaceDecl.

Wrong declaration AST coming out of quotation?

The information about the return type of functions in arrays seems to be spread out into very distant parts of AST -- so much so it appears.. not really rationalizable for a bystander armed with a general knowledge of C.

This can be illustrated with two cases -- functions returning "void" and "void *" -- note how the "void" piece is part of the outer DeclSpec and the "pointer to" piece is buried within Array->Ptr->OldProto:

(Note: the outer DecDef has been dropped for posterity. The examples were obtained using GHCi with language-c-quote version 0.11.4)

[cedecl|void *(*foo[2])();|]

InitGroup (DeclSpec [] [] (Tvoid noLoc) noLoc)
          []
          [Init (Id "foo" noLoc)
                (Array []
                       (ArraySize False (Const (IntConst "2" Signed 2 noLoc) noLoc) noLoc)
                       (Ptr [] (OldProto (Ptr [] (DeclRoot noLoc) noLoc) [] noLoc) noLoc)
                       noLoc)
                Nothing Nothing [] noLoc] noLoc

[cedecl|void (*foo[2])();|]

InitGroup (DeclSpec [] [] (Tvoid noLoc) noLoc)
          []
          [Init (Id "foo" noLoc)
                (Array []
                       (ArraySize False (Const (IntConst "2" Signed 2 noLoc) noLoc) noLoc)
                       (Ptr [] (OldProto (DeclRoot noLoc) [] noLoc) noLoc)
                       noLoc)
                Nothing Nothing [] noLoc] noLoc) noLoc

language-c-quote 0.7.7 requires old mtl version

Currently language-c-quote-0.7.7 requires mtl-2.1.3.1 (current is mtl-2.2.0.1), which breaks e.g. accelerate-cuda installation on ghc 7.8.2.

Missing braces cause dangling-else

Consider the following module:

{-# LANGUAGE QuasiQuotes #-}
module DanglingElse where

import Language.C.Quote.C
import Text.PrettyPrint.Mainland
import Text.PrettyPrint.Mainland.Class

import System.IO

mainProg = [cunit|
  $esc:("#include <stdio.h>")

  int main() {
    int x = 1;
    if (x > 1) {
      // This comment is needed to trigger the dangling-else problem
      if (x > 2) {
        printf("a\n");
      }
    } else {
      printf("b\n");
    }
  }|]

main = do
  withFile "dangling.c" WriteMode $ \h -> do
    hPutDocLn h $ ppr mainProg

Running main will create dangling.c with the following contents:

#include <stdio.h>
int main()
{
    int x = 1;

    if (x > 1)
        // This comment is needed to trigger the dangling-else problem
        if (x > 2)
            printf("a\n");
    else
        printf("b\n");
}

As you can see, the braces around the body of the outer if are missing. As a result, we have a dangling-else clause, which can be attributed to any of the ifs. Compiling the file with clang 4.0.1 yields the following warning:

$ clang -o dangling dangling.c
dangling.c:10:5: warning: add explicit braces to avoid dangling else [-Wdangling-else]
    else
    ^
1 warning generated.

Running the resulting executable produces no output, from which we conclude that the else clause is interpreted as belonging to the inner if, contrary to our intention. We believe that it is a bug.

Interestingly, the problem goes away when we remove the C comment line from the quoted C fragment, which results in the braces being present.

As a workaround, we may insert a dummy statement (a ;) before the comment line, which also makes the problem go away.

The antiquoter for double and float does not handle infinity correctly

If you antiquote a positive infinite value, you will get the expression Infinity (I think it just calls show on the float). There may not be a sensible thing to do here (you can always just define a constant Infinity yourself). C99 does define INFINITY in math.h, which may be slightly better than the current behaviour.

It is likely that a similar issue exists for NaNs.

Missing antiquotation when using inits antiquoter

Consider this code fragment:

let values :: [C.Initializer]
      values = [[C.cinit|2|]]
      def = [C.cedecl|int $id:name[] = {$inits:values};|]
in ...

This leaves an AntiInits node in the resulting syntax tree. The most likely cause is that qqInitializerListE is defined for arguments of type [C.Initializer], but that type does not ever actually appear; rather the syntax tree contains [(Maybe C.Designation, C.Initializer)].

Build failure with Stackage Nightly

Language/C/Parser/Lexer.x:604:17: error:
    • Couldn't match type ‘PState’ with ‘()’
        arising from a functional dependency between:
          constraint ‘MonadState () P’ arising from a use of ‘get’
          instance ‘MonadState PState P’
            at Language/C/Parser/Monad.hs:167:10-28
    • In a stmt of a 'do' block: st <- get
      In the expression:
        do { beg <- getInput;
             sc <- getLexState;
             st <- get;
             case alexScanUser st beg sc of {
               AlexEOF -> return $ L (alexLoc beg beg) Teof
               AlexError end
                 -> lexerError end (text rest)
                 where
                     rest :: String
                     ....
               AlexSkip end _ -> setInput end >> lexToken
               AlexToken end len t -> setInput end >> t beg end } }
      In an equation for ‘nextToken’:
          nextToken
            = do { beg <- getInput;
                   sc <- getLexState;
                   st <- get;
                   .... }