llvm dev - Sep 2021 - Disabling inline compilation (Clang with VS2019)

On 22/09/2021 16:09, John Emmas via llvm-dev wrote:
>
> it's strange that the inlining seems to be different for us (unless 
> it's some other project setting??)
>
Anyway, ignoring the "/Ob0" issue for a minute, maybe there's a
better
solution available...

Could compilations be adapted so that wherever a symbol is found to be 
declared as __declspec(dllimport) there's an automatic assumption that 
it shouldn't be inlined?

John

> Anyway, ignoring the "/Ob0" issue for a minute, maybe there's
a better
> solution available...
> 
> Could compilations be adapted so that wherever a symbol is found to be
> declared as __declspec(dllimport) there's an automatic assumption that
> it shouldn't be inlined?
+rnk who is much better in tune with MSVC compatibility than I am.

In general, Clang is willing to inline a function defined in-class
because of the One Definition Rule; C++ says we can assume that the
definition is the same everywhere.  As I said, I don't see Clang
inlining the method, but Godbolt does, I don't know what the difference
is there.

In the specific example, moving the method definition out of the class
should avoid the problem; but if you have a large number of methods
like this, that's a real lot of work and it would be nice to find some
other solution.

If MSVC promises not to inline a dllimport method, that seems like
something Clang should take into consideration in MS-compatibility
mode.  Probably implicitly marking dllimport methods as noinline would
be sufficient, but I think we'd be willing to do that only if MSVC
actually makes that promise explicitly.
--paulr