On Windows, can't create constexpr assignment for function pointer of function marked with dllimport

[cgagnon-mw]

I couldn't find this issue reported here, but if it's already been handled, feel free to archive this.

This code compiles on Mac and Linux (using the equivalent import/export annotations), but not on Windows:

class __declspec(dllimport) MyClass {
    public:
     int* foo(int) const;
};
static constexpr auto(MyClass::*bar)(int) const = &MyClass::foo;

Here's the error output:

<source>:6:33: error: constexpr variable 'bar' must be initialized by a constant expression
static constexpr auto(MyClass::*bar)(int) const = &MyClass::foo;
                                ^                 ~~~~~~~~~~~~~

The program compiles on Windows if you replace dllimport with dllexport.
It also compiles if you simply remove constexpr. Using constinit gives essentially the same error.

Here's a similar issue report for MSVC (not authored by me).
https://developercommunity.visualstudio.com/t/cannot-constinitconstexpr-initialize-a/10456333

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (cgagnon-mw)

I couldn't find this issue reported here, but if it's already been handled, feel free to archive this.

This code compiles on Mac and Linux (using the equivalent import/export annotations), but not on Windows:

class __declspec(dllimport) MyClass {
    public:
     int* foo(int) const;
};
static constexpr auto(MyClass::*bar)(int) const = &MyClass::foo;

Here's the error output:

<source>:6:33: error: constexpr variable 'bar' must be initialized by a constant expression
static constexpr auto(MyClass::*bar)(int) const = &MyClass::foo;
                                ^                 ~~~~~~~~~~~~~

The program compiles on Windows if you replace dllimport with dllexport.
It also compiles if you simply remove constexpr. Using constinit gives essentially the same error.

Here's a similar issue report for MSVC (not authored by me).
https://developercommunity.visualstudio.com/t/cannot-constinitconstexpr-initialize-a/10456333

[shafik]

CC @AaronBallman

[frederick-vs-ja]

Possibly a duplicate of #50900, although the old issue was about address of dllimported objects.

[AaronBallman]

I think this is morally equivalent to #50900; CC @rnk @zmodem for additional opinions

[rnk]

I would say this is working-as-intended: Clang is correct that this global variable cannot meet the requirements of constexpr evaluation and will require dynamic initialization, but it would be good to ground that understanding in the standardese for constexpr.

Clang is correct that the address of an imported function is not knowable at compile or link time. You can't build a global table of function pointers (i.e. a vtable) to dllimported functions. If you do this, you'll see that Clang and MSVC emit dynamic initialization helpers to fill in those dllimported values at startup.

[cgagnon-mw]

For the behavior, I think it all comes down to how much you care about dynamic initialization. Maybe my perspective is warped from working on compilers, but I always felt like that was a huge part of the value of constexpr: if I mark a global constexpr, I can rely on it being initialized before other initializers run. It's possible that users don't care as much about that as they care about doing the rest of the computation at compile time.

Reading this on the discussion for #50900, I thought I'd give a +1 that I care more about "doing the rest of the computation at compile time" than about when the function pointer is actually initialized.

Initializing constexpr globals before other globals in order to accept this program sounds great to me.