Emilio Cobos Álvarez
Emilio Cobos Álvarez
I can see from the error what it's trying to do... Here you got a test-case: ```h static int foo; struct bar { int foo: 10; }; ```
btw, I think this shouldn't be a hard error, it's just unfortunate, specially when it works in extern "C" functions.
Yeah, these are not necessarily unfixable though :) I think we should not generate a bunch of these constants #1838. Same goes for the typedefs. I haven't been catching up...
I appreciate a lot all the reduced test-cases @Volker-Weissmann, thank you!
Let's add them here, so the code doesn't land untested.
How is `_IO` defined? Grepping `define _IO` in my `/usr/include/linux` dir didn't yield anything.
As in... If we don't know how `_IO` is defined, how could we generate a sensible constant?
That being said, even with that it doesn't work (huh, I'd swear we knew how to deal with macro expansions): ```c #define _IO(a_) (a_) #define UI_DEV_CREATE _IO(1) #define UI_DEV_DESTROY _IO(2)...
This is probably a bug for rust-cexpr. Indeed, it's a dupe of https://github.com/jethrogb/rust-cexpr/issues/3.
I guess I can try to add to libclang a way to get whether the macro definition belongs to a functional macro...