[cfe-dev] Latest clang and dllimport

[Reid Kleckner]

I don't think we have any feature test flags for diagnostic changes.

It sounds like the general problem is that two headers declare parts of the
win32 API because windows.h is too much of a header dependence. Boost also
isn't sure sure whether windows.h, from mingw or Microsoft, is using
dllimport or not. Past versions of mingw have been inconsistent, so you
can't just always declare it dllimport, like it should be.

I'm starting to feel like we should just downgrade this to a warning for
free functions. We already make it a warning in other cases. Very few
programs rely on function pointer identity, but global variable identity is
often important.

Sound reasonable?

On Tue, Jul 21, 2015 at 12:36 PM, Edward Diener <
eldlistmailingz at tropicsoft.com> wrote:

> In the latest clang built from source, if a function is mismatched as to a
> difference in dllimport attributes clang produces an error. As in:
>
> C:\Utilities\mingw-w64\i686-5.1.0-posix-dwarf-rt_v4-rev0\mingw32\i686-w64-mingw32\include\synchapi.h:127:26:
> error: redeclaration of 'Sleep' cannot add 'dllimport' attribute
>   WINBASEAPI VOID WINAPI Sleep (DWORD dwMilliseconds);
>                          ^
> ..\..\..\boost/smart_ptr/detail/yield_k.hpp:67:29: note: previous
> declaration is here
>   extern "C" void __stdcall Sleep( unsigned long ms );
>
> Changing the latter to:
>
>   extern "C" __declspec(dllimport) void __stdcall Sleep( unsigned long ms
> );
>
> fixes the problem for clang.
>
> Earlier versions of clang ( 3.4.1, 3.5.2, 3.6.1 ) did not have this
> problem. Is there a __has_feature or __has_extension that I can use to test
> this change in the latest clang ? The previous versions are also happy with
> the __declspec(dllimport) added in the declaration so even without a
> __has_feature or __has_extension I can just test for clang on Windows, but
> I like to be as precise as possible in Boost code.
>
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150721/2e146f04/attachment.html>