[llvm-bugs] [Bug 43282] New: Preprocessor bug/incompatibility regarding __VA_ARGS__ and comma when compiling with -fms-compatibility on Windows

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43282

            Bug ID: 43282
           Summary: Preprocessor bug/incompatibility regarding __VA_ARGS__
                    and comma when compiling with -fms-compatibility on
                    Windows
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: ToHe_EMA at gmx.de
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

We are currently exploring to compile our software on Windows with Clang, but
hit a couple Clang/LLVM bugs along the way. This one is about incorrect
emulation of preprocessor.

Minimal code to reproduction the problem:
#define BUILD_LIB_XYZ ,
#define DLL(...) COMBINE(DLL_HELP_GET_THIRD_ARGUMENT(__VA_ARGS__, "dllexport",
"dllimport"))
#define DLL_HELP_GET_THIRD_ARGUMENT(A, B, C, ...) C
#define COMBINE(...) __VA_ARGS__
static_assert(0, DLL(BUILD_LIB_XYZ));

The code should output "dllexport" because DLL() gets a comma inside the
__VA_ARGS__ which shifts the "dllexport" from the second to the third argument.
However on Clang with -fms-compatibility this is not the case, and "dllimport"
is printed instead. Note that only on Microsoft's compiler the COMBINE is
necessary to get this correct behavour.

Background: In our software project we use this preprocessor trick to choose
between __declspec(dllimport) and __declspec(dllexport) (or actually
__attribute__((dllexport)) and __attribute__((dllimport)) on Clang). It works
like this: In the build system we define a preprocessor symbol like
BUILD_LIB_XYZ=, only when building library XYZ. This automatically evaluates to
DLLEXPORT for all the API of library XYZ and DLLIMPORT for everything else
without having to setup new macros for each library. It worked fine on
Microsoft's Compiler since at least 2015, GCC and even Clang, normally at
least. However not when provided with -fms-compatibility. We cannot disable
that option either though because our source files sometimes use <Windows.h>
for platformspecific API and as far as we know, there is no way to only
selectively apply -fms-compatibility for certain #includes.

Live code on Godbolt: https://gcc.godbolt.org/z/KODv16

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190911/6ebd2443/attachment.html>