[cfe-users] Clang (with Visual Studio) wrongly complains about missing variables

[David Blaikie via cfe-users]

On Thu, Sep 23, 2021 at 3:34 AM John Emmas via cfe-users <
cfe-users at lists.llvm.org> wrote:

> On 22/09/2021 18:21, Reid Kleckner via cfe-users wrote:
> > Looking back in the thread, I found the example code, and I see that
> > MSVC refuses to inline this helper, but clang will inline it. I
> > believe clang is permitted to inline it, MSVC will export the static
> > data member (_the_keyboard), so everything should work as long as you
> > provide a definition of _the_keyboard in the DLL and set -DBUILDING_DLL.
> >
>
> Thanks for coming in on this, Reid. As Jeff suggested, I transferred the
> question to llvm-dev where there's a small discussion going on now.  I
> must admit though, my personal view is that declaring something as
> __declspec(dllimport) should automatically exclude it from being inlined
> (I'm pretty sure that's what Microsoft itself does...)
>
> Ultimately, the main advantage of a DLL is that it offers dynamic
> linkage. In other words, DLL features can be updated simply by updating
> the DLL (i.e. without needing to update all the apps which use it). In
> the dim old days this could lead to something called "DLL Hell" but
> WinSxS has largely consigned that to history now.  So whilst inlining
> code from a DLL might seem like a good idea, it throws away the main
> advantage of DLL's without offering anything better.
>

Presumably it offers the benefit of inlining optimizations - so there's
probably some execution speed improvement to tradeoff. (& a way the user
can address the issue by moving functions out of line)

Over on llvm-dev I'm trying to persuade them that declaring something as
> __declspec(dllimport) should automatically exclude it from being
> inlined.  And to be honest, I'd be quite surprised if that's not what
> Microsoft intended.
>

I think if it's clearly demonstrated that that's Microsoft's implementation
- that no matter how hard you ask it to optimize and how simple the
function is, that it won't inline a dllexported function that's inline in a
header (both implicitly inline in a class definition, and probably check
the case of a standalone dllexported inline non-member function in a
header) that I'd say (though I have little sway/weight in this design
decision) clang-cl should implement the same behavior, because it is
observable/can be relied upon as you have (though also - dllexported
variables should be defined somewhere, generally) & an opt-in flag to what
is the current behavior (dllexport-inlining).

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20210923/de4a836e/attachment.html>