pythonh: Function type does not match previously declared function with the same mangled name: stat64

[andre2007]

This dockerfile

FROM python:3.7

RUN apt-get update && apt-get upgrade -y \
    && apt-get install --no-install-recommends -y curl gcc clang-7 libclang-7-dev python3 python3-dev xz-utils \
    && ln -s /usr/bin/clang-7 /usr/bin/clang

WORKDIR /tmp
RUN curl -OL https://github.com/ldc-developers/ldc/releases/download/v1.22.0/ldc2-1.22.0-linux-x86_64.tar.xz \
    && tar -xf ldc2-1.22.0-linux-x86_64.tar.xz --strip-components=1 -C /

RUN echo '#include <python3.7/Python.h>' > pythonh.dpp
RUN DFLAGS="-L=-L/usr/lib/llvm-7/lib/" dub run dpp -- pythonh.dpp \
    --preprocess-only

will produce a file pythonh.d which contains this coding

pragma(mangle, "stat64") int stat64_(const(char)*, stat64*) @nogc nothrow;
int fstat(int, stat*) @nogc nothrow;
pragma(mangle, "stat64") int stat_(const(char)*, stat*) @nogc nothrow;

LDC2 complains:

pythonh.d(150): Error: Function type does not match previously declared function with the same mangled name: stat64
pythonh.d(150): Previous IR type: i32 (i8*, %pythonh.stat64*)
pythonh.d(150): New IR type: i32 (i8*, %pythonh.stat*)

[atilaneves]

Ah. I never noticed it before because I only ever used dmd on the result and ldc is a bit more of a stickler wrt duplicate symbols. A workaround for now is to use dmd instead.

[atilaneves]

For some reason libclang is returning "stat64" as the mangling for "stat" even though, as C linkage functions, they don't mangle!

[atilaneves]

I'm racking my head how to solve this without having to try and reduce the issue with libclang. There's no good way to know if the cursor is C or C++ (thereby avoiding any mangling whatsoever if not needed, as is the case here). There's a function to get the language, but it returns "C" for any and all functions regardless of them being extern "C" or not. There's a function to get linkage, but it doesn't do what you'd expect and basically tells you if a cursor is extern or not.

[Laeeth]

cling can do a lot of things that libclang cannot. one of those things might be wrap the parts of clang + associated related code not in libclang.

…

-- Laeeth Isharc [email protected]

On Wed, 26 Aug 2020, at 3:50 PM, Atila Neves wrote: I'm racking my head how to solve this without having to try and reduce the issue with libclang. There's no good way to know if the cursor is C or C++ (thereby avoiding any mangling whatsoever if not needed, as is the case here). There's a function to get the language, but it returns "C" for any and all functions regardless of them being `extern "C"` or not. There's a function to get linkage, but it doesn't do what you'd expect and basically tells you if a cursor is extern or not. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#271 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSV67TNIK3CHGEHU4IUIXTSCUOL7ANCNFSM4P53FUHQ>.

[andre2007]

If my understanding is correct, with this pr it will be a deprecation warning also with DMD dlang/dmd#8429