This of course seems related to  issue 773476 . I searched for a similar report but couldn't find any. Ran into this when I updated my Visual Studio and it installed .16299 but I was previously still on .14393 (I'm one of those strange people who doesn't use any of the depot_tools provided stuff).

TL;DR - you are somehow getting the 16299 header files and that is not supposed to happen.

Do you have the 15063 SDK installed? That SDK is required because 14393 is too old, and 16299 has this bug (and others).

I modified the setup_toolchain.py script to prefer 15063 over 16299 but if you don't have 15063 installed that may not work. This happened in crrev.com/c/714366, October 12th.

Previously there was a *separate* incompatibility between clang and the 16299 header files but once that is/was resolved this new issue appears - I saw it for the first time last night.

This saves me the trouble of opening an issue for that problem. I'm already talking to Microsoft about this issue and I'll mark this as blocking 773476.

Until then:
- Make sure you have the 15063 SDK installed (the final version, previous versions were buggy)
- Make sure that you run "gclient runhooks" from a clean command prompt, with no lib/include environment variables set.
- Do a "gn clean" to ensure that all vestiges of the old environment are purged - they seem to hang around somehow sometimes

re comment 2: is this clang-only? If so, we can fix that. How is IID_IViewModePreferencesStatics declared? I remember IIDs being __declspec(selectany) and us having some trouble with that in the past (e.g. http://llvm.org/PR23242) -- we thought we had fixed them, but maybe dllimport'ed selectanys don't work and this is one, or something like that.

(here are some internal slides on declspec(selectany), possibly unrelated, mostly as note to self: https://docs.google.com/presentation/d/1QxSYM4L8J5m6enZQxBIZT85E_6AYdSsBnjsSAxZc_7Q/edit#slide=id.ge0df14381_0_158)

+hans in case this is clang-only

Yes, this is clang only. Microsoft gave me a fixed wrl\implements.h (and I think clang has also been updated to handle their odd inheritance?) so I ran a try job with the Fall Creators Update SDK. You can see the failures on the clang builders here:

https://chromium-review.googlesource.com/c/chromium/src/+/746145

The previous packaging of the Fall Creators Update SDK is here (no patching of wrl\implements.h) - try jobs running:

https://chromium-review.googlesource.com/c/chromium/src/+/740569

> How is IID_IViewModePreferencesStatics declared?

We fixed wrl\implements.h in clang but that hasn't made it into chromium's clang yet btw --  issue 775171  tracks that.

I'm confused as to how the original reporter was able to get to this error given that the wrl\implements.h issue should have stopped the build earlier. Curious.

After patching in the latest SDK I can look in this file:

third_party\depot_tools\win_toolchain\vs_files\264b4f41744f2e87ca68693d939ee19e681c4fc3\win_sdk\Include\10.0.16299.0\winrt\windows.ui.viewmanagement.h

and see this:

#ifndef ____x_ABI_CWindows_CUI_CViewManagement_CIViewModePreferencesStatics_FWD_DEFINED__
#define ____x_ABI_CWindows_CUI_CViewManagement_CIViewModePreferencesStatics_FWD_DEFINED__
namespace ABI {
    namespace Windows {
        namespace UI {
            namespace ViewManagement {
                interface IViewModePreferencesStatics;
            } /* Windows */
        } /* UI */
    } /* ViewManagement */} /* ABI */
#define __x_ABI_CWindows_CUI_CViewManagement_CIViewModePreferencesStatics ABI::Windows::UI::ViewManagement::IViewModePreferencesStatics


Then later it has this:

#if WINDOWS_FOUNDATION_UNIVERSALAPICONTRACT_VERSION >= 0x40000
#if !defined(____x_ABI_CWindows_CUI_CViewManagement_CIViewModePreferencesStatics_INTERFACE_DEFINED__)
#define ____x_ABI_CWindows_CUI_CViewManagement_CIViewModePreferencesStatics_INTERFACE_DEFINED__
extern const __declspec(selectany) _Null_terminated_ WCHAR InterfaceName_Windows_UI_ViewManagement_IViewModePreferencesStatics[] = L"Windows.UI.ViewManagement.IViewModePreferencesStatics";
namespace ABI {
    namespace Windows {
        namespace UI {
            namespace ViewManagement {
                /* [object, uuid("69B60A65-5DE5-40D8-8306-3833DF7A2274"), exclusiveto, contract] */
                MIDL_INTERFACE("69B60A65-5DE5-40D8-8306-3833DF7A2274")
                IViewModePreferencesStatics : IInspectable
                {
                    virtual HRESULT STDMETHODCALLTYPE CreateDefault(
                        /* [in] */ABI::Windows::UI::ViewManagement::ApplicationViewMode mode,
                        /* [retval, out] */__RPC__deref_out_opt ABI::Windows::UI::ViewManagement::IViewModePreferences * * result
                        ) = 0;
                    
                };

                extern MIDL_CONST_ID IID & IID_IViewModePreferencesStatics=_uuidof(IViewModePreferencesStatics);
                
            } /* Windows */
        } /* UI */
    } /* ViewManagement */} /* ABI */

EXTERN_C const IID IID___x_ABI_CWindows_CUI_CViewManagement_CIViewModePreferencesStatics;
#endif /* !defined(____x_ABI_CWindows_CUI_CViewManagement_CIViewModePreferencesStatics_INTERFACE_DEFINED__) */
#endif // WINDOWS_FOUNDATION_UNIVERSALAPICONTRACT_VERSION >= 0x40000




Note also that if you look at the failures for https://chromium-review.googlesource.com/c/chromium/src/+/746145 there are actually *two* sets of failures - the duplicate symbols and complaints about "error: missing 'typename' prior to dependent type name 'DelegateHelper::Interface". Maybe it depends on debug/release or component/non-component?

                extern MIDL_CONST_ID IID & IID_IViewModePreferencesStatics=_uuidof(IViewModePreferencesStatics);

with

#pragma push_macro("MIDL_CONST_ID")
#if !defined(_MSC_VER) || (_MSC_VER >= 1910)
#define MIDL_CONST_ID constexpr const
#else
#define MIDL_CONST_ID const __declspec(selectany)
#endif


So I guess the >= 1910 disables selectany, and cl.exe has different ideas on if extern constexpr const references with initializers should be definitions. Pretty sure they should be definitions, so this looks like a header bug.

Standard: "The constexpr specifier shall be applied only to the definition of a variable or variable template" So this better be a definition, but then it's going to be emitted everywhere.

Aha, https://docs.microsoft.com/en-us/cpp/build/reference/zc-externconstexpr looks related. If we built with /Zc:externConstexpr then I'd guess that cl.exe would error out too. Can someone verify that?

So we might have to implement /Zc:externConstexpr (apparently with the broken default, maybe with a warning or only in system headers) in clang-cl.

(I wrote this while Bruce's was writing his, so some duplication)

please file separate bug for DelegateHelper::Interface

/Zc:externConstexpr is very new - 15.5 preview required - but I had that installed and confirmed that when building with that switch I see exactly the same linker error.

I'll file an SDK/VS bug for the bad header, and a separate Chromium bug for the DelegateHelper::Interface issue, which seems likely to be yet another SDK bug. It sounds like Microsoft *might* be able to fix these somewhat quickly (maybe within a month or so? just my guessing) so if any of the fixes are really ugly on the clang side...

I filed https://developercommunity.visualstudio.com/content/problem/141665/midl-const-id-is-defined-incorrectly-leading-to-li.html and I am following up with the SDK team.

I have confirmed that updating all 294 places that define MIDL_CONST_ID like this avoids the problem:

#if !defined(_MSC_VER) || (_MSC_VER >= 1910)
#define MIDL_CONST_ID constexpr const __declspec(selectany)
#else
#define MIDL_CONST_ID const __declspec(selectany)
#endif

I believe that using the second definition also resolves the issue and there are probably other solutions, such as removing the 'extern'.

I filed https://bugs.llvm.org/show_bug.cgi?id=36413 to implement /Zc:externConstexpr[-] in Clang.

Microsoft's Spring 2018 (whatever that update will be called) insider SDK has resolved this issue. Closing as Fixed.