This is an archive of the discontinued LLVM Phabricator instance.

[MS] Consder constexpr globals to be inline, as in C++17
ClosedPublic

Authored by rnk on Jun 8 2018, 11:25 AM.

Details

Summary

Microsoft seems to do this regardless of the language mode, so we must
also do it in order to be ABI compatible.

Fixes PR36125

Diff Detail

Repository
rL LLVM

Event Timeline

rnk created this revision.Jun 8 2018, 11:25 AM
thakis added inline comments.Jun 8 2018, 12:29 PM
clang/lib/Sema/SemaDecl.cpp
6597 ↗(On Diff #150546)

Is this related to /Zc:externConstexpr / PR36413? If so, maybe we should do the standards-conforming thing by default and ask people to pass /Zc:externConstexpr- if they need ABI compat?

Want to add a FIXME about doing this in the AST in the source too?

rnk added inline comments.Jun 20 2018, 3:30 PM
clang/lib/Sema/SemaDecl.cpp
6597 ↗(On Diff #150546)

The way I see it, doing the C++17 thing by default is in some ways more standards-conforming. We're opting people into the new rules earlier on this platform because we have to be ABI compatible with the other compiler.

Also, I think this is unrelated to /Zc:externConstexpr: "By default, Visual Studio always gives a constexpr variable internal linkage, even if you specify the extern keyword." That's not what we're doing here. We're marking these things inline, which means they will be merged across TUs, as they would if the user explicitly added __declspec(selectany).

rsmith added a subscriber: rsmith.Jun 20 2018, 3:54 PM

Can we now remove the corresponding MSVC-specific hacks elsewhere (eg, ASTContext::isMSStaticDataMemberInlineDefinition), or do we still need those for const-but-not-constexpr static data members?

rnk added a comment.Jun 20 2018, 4:14 PM

Can we now remove the corresponding MSVC-specific hacks elsewhere (eg, ASTContext::isMSStaticDataMemberInlineDefinition), or do we still need those for const-but-not-constexpr static data members?

We should be able to do that, but unfortunately it drastically changes the diagnostics we emit, as you can see from the tortured ifdefs in my test case updates. I gave up before attempting it.

thakis accepted this revision.Jun 21 2018, 6:33 AM

Thanks for explaining, makes sense to me.

This revision is now accepted and ready to land.Jun 21 2018, 6:33 AM
rnk updated this revision to Diff 219638.Sep 10 2019, 5:21 PM
  • rebase
Herald added a project: Restricted Project. · View Herald TranscriptSep 10 2019, 5:21 PM
Herald added a subscriber: mstorsjo. · View Herald Transcript
rnk added a comment.Sep 10 2019, 5:24 PM
In D47956#1138555, @rnk wrote:

Can we now remove the corresponding MSVC-specific hacks elsewhere (eg, ASTContext::isMSStaticDataMemberInlineDefinition), or do we still need those for const-but-not-constexpr static data members?

We should be able to do that, but unfortunately it drastically changes the diagnostics we emit, as you can see from the tortured ifdefs in my test case updates. I gave up before attempting it.

Coming back to this a year later, I think I got confused. This patch is good to go, but I never landed it because I wanted to implement Richard's comment. I guess I'll go forward with this and see what breaks. The main thing seems to be that now applying dllexport to some static data members outside the class body becomes a warning instead of a hard error. So, we should be more accepting with this than we were previously.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptSep 11 2019, 11:07 AM