It looks like this warning only fires for functions that are referenced, and it looks like all these methods are only referenced in parser.cc, where they do have a definition.

I don't yet understand why we don't get this warning in win component builds, where the inline functions should get dllexported -- I guess we skip dllexported inlines without definition silently, and then the posix reasoning applies?

So I suppose this points out some deficiency in my clang patch where we now create ASTs where inline functions are marked referenced but don't have a definition?

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/d4219df603e902eb0ae7f1fd02d55d16522eb15b

commit d4219df603e902eb0ae7f1fd02d55d16522eb15b
Author: Takuto Ikuta <tikuta@chromium.org>
Date: Mon Nov 05 08:56:26 2018

Remove V8_INLINE from non-inlineable function from parser.h

I will enable /Zc:DllexportInlines- flags for faster build time on windows.
But the flag makes clang's -Wundefined-inline check more strict as a secondary effect.

Actually, having inline function specifier for the function not defined in header file seems bit strange.
Let me remove inline specifier from such functions.

Bug: chromium:857548,  chromium:901709 
Change-Id: Ic06d10e2445cfedc7af67b72154f93a51ac26853
Reviewed-on: https://chromium-review.googlesource.com/c/1186017
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57229}
[modify] https://crrev.com/d4219df603e902eb0ae7f1fd02d55d16522eb15b/src/parsing/parser.h

+hans who might know why we /zc:dllexportInlines- might make this warning fire more here.

thakis@, is this actually blocking issue to enable the flag in 901709 ?
Do you think we need to do something additionally before enabling the flag?

Taking a look today. I don't expect this will block anything, but it would be good to understand the situation.

What Hans said. Not a hard blocker, but it would be good to understand.

Okay, the difference is due to how -Wundefined-inline interacts with dllexport/import functions.

Example:

  struct S {
    inline void foo();
  };

  void use(S *s) { s->foo(); }


but not here:

  struct __declspec(dllexport) S {
    inline void foo();
  };

  void bar(S *s) { s->foo(); }

Applying the /Zc:dllexportInlines- flag makes the second case be treated as the first, i.e. S::foo() is not dllexport.


Sema::getUndefinedButUsed() will ignore dllexport functions with the reasoning that because of their linkage being weak_odr instead of linkonce_odr, the definition will be emitted if it occurs in another file, even if it's not referenced there.

(That was added in Clang r209471 after discussing with Richard, see https://codereview.chromium.org/298913006/#msg9)

Or to put it another way: -Wundefined-inline figures that a regular inline function needs to be defined in the same TU where it's used, but a dllexport inline function may be defined in a TU where it's not used.