aganea wrote:
> Trying to wrap my head around this. Part of the weirdness comes from having
> an initializer for a dllimport variable in the first place.
>
> We would typically not allow:
>
> ```
> __declspec(dllimport) int x = 42;
> ```
>
> `(error: definition of dllimport data)`
>
> But we allow it when the dllimport is inherited via the function for a static
> local, because otherwise a lot of code would break:
>
> ```
> __declspec(dllimport) constexpr const int* f() {
> static constexpr int x = 42;
> return &x;
> }
> ```
>
> We already seem okay evaluating the address as a constant expression:
>
> ```
> __declspec(dllimport) constexpr const int* f() {
> static constexpr int x = 42;
> return &x;
> }
> static_assert(*f() == 42);
> ```
>
> But not like this:
>
> ```
> __declspec(dllimport) constexpr const int* f() {
> static constexpr int x = 42;
> static constexpr const int *p = &x;
> return p;
> }
> static_assert(*f() == 42);
> ```
>
> Even though it's really the same thing? I'm not sure why those two are
> different (that would be interesting to know!).
Not exactly the same thing, thus this PR :-) Both static local `VarDecl`s
inherit the `dllimport` attribute from the function declaration, here:
https://github.com/llvm/llvm-project/blob/e741cd88a10b89032481c705e949899abbf909aa/clang/lib/Sema/SemaDecl.cpp#L15078
- that is code you've added here:
https://github.com/llvm/llvm-project/commit/59f18f1b72941 (I suppose to
guarantee that the address of the static local is guaranteed to be the same
accross all loaded modules)
However once we get in constexpr init evaluation, that dllimport attribute was
preventing the initialization, unlike cl.exe. Thus the changes in this PR.
> Maybe this is a simpler test case to work with?
It's a bit different because the function has to be "inline" explicitly,
otherwise we get:
```
> clang-cl /c main.cpp
main.cpp(1,34): error: dllimport cannot be applied to non-inline function
definition
1 | __declspec(dllimport) const int* f() {
| ^
1 error generated.
```
But I can do that instead, I'll check if it covers the same case as in our
codebase.
> In the updated comment, you add "For the [static local] case, we'd still need
> to evaluate the constant expression in case we're inside a (inlined)
> function."
>
> But isn't there a risk that the expression can leak outside the function, and
> we way try to use it in some constexpr context where it doesn't actually work?
Do you have an example in mind?
https://github.com/llvm/llvm-project/pull/171628
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
