error: '#' is not followed by a macro parameter

[denizzzka]

I'm not sure about correctness of this C header code:

/* bug.h file */

/* This code copied from libopencm3 project */

#define GPIO_AFR(n, af)         ((af) << ((n) * 4))
#define GPIO_AFR_MASK(n)        (0xf << ((n) * 4))

But for some reason it processed into:

extern(C)
{
    #define GPIO_AFR( n , af ) ( ( af ) << ( ( n ) * 4 ) ) #

    #define GPIO_AFR_MASK( n ) ( 0xf << ( ( n ) * 4 ) )

}

(with trailing '#' symbol at GPIO_AFR)

This causes error:

test.d.tmp:55:30: error: '#' is not followed by a macro parameter
   55 |     #define GPIO_AFR( n , af ) ( ( af ) << ( ( n ) * 4 ) ) #
      |                              ^
Error: Could not run `cpp test.d.tmp`:
# 1 "test.d.tmp"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "test.d.tmp"

[denizzzka]

Tested on ~master with libclang 1:7.0.1-9+b2 installed on Debian

[atilaneves]

I can't reproduce that with libclang 9 on my machine after copying the C code as-is into a test. I can't reproduce it on Travis with libclang 7 either.

[denizzzka]

I can't reproduce that with libclang 9 on my machine after copying the C code as-is into a test.

Maybe it is reproduceable only if CLI is used? My test suite is only two small files:

$ cat bug.h
/* This code copied from libopencm3 project */

#define GPIO_AFR(n, af)         ((af) << ((n) * 4))
#define GPIO_AFR_MASK(n)        (0xf << ((n) * 4))

$ cat test.dpp
#include "bug.h"

void test() {
    enum x = GPIO_AF0;
}

Run:

$ d++ --preprocess-only --keep-pre-cpp-files test.dpp
test.d.tmp:55:30: error: '#' is not followed by a macro parameter
   55 |     #define GPIO_AFR( n , af ) ( ( af ) << ( ( n ) * 4 ) ) #
      |                              ^
Error: Could not run `cpp test.d.tmp`:
...

[denizzzka]

Thank you!

Problem found!

libclang bindings settings uses just libclang name for linking to clang library, but in Debian we haven't this name (only with version specified like libclang-8.so.1)

And for unknown reason on my system was installed softlink from /usr/lib/libclang.so to old external google-android-build-tools-installer package with buggy libclang.

[atilaneves]

Maybe it is reproduceable only if CLI is used?

That's never the case - the test suite and main function are written on purpose in such a way that they can't act differently.

Problem found!

Good!