This is an archive of the discontinued LLVM Phabricator instance.

[C++20][Modules] Implement P2615R1 exported specialization diagnostics.
Changes PlannedPublic

Authored by iains on Jun 22 2023, 6:07 AM.

Details

Reviewers
ChuanqiXu
Summary

P2615R1 introduces diagnostics for partial and explicit specializations in module export declarations. This is applied as a DR to C++20.

Two testcases are removed since they were testing behaviour of imported specialisations (which are no longer permitted as exports).
Three testcases are amended to remove exports of specialisations, but retain the remainder of the test.

Diff Detail

Event Timeline

iains created this revision.Jun 22 2023, 6:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 22 2023, 6:07 AM
Herald added a subscriber: ChuanqiXu. · View Herald Transcript
iains added subscribers: Restricted Project, h-vetinari.
iains published this revision for review.Jun 22 2023, 6:12 AM

I think it is a good idea to keep this part of P2615R1 separate from the unnamed exports diagnostics [the parent commit] - it seems likely that there will be more fallout from this (given that there were already PRs about the behaviour of exported specialisations).

Herald added a project: Restricted Project. · View Herald TranscriptJun 22 2023, 6:12 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
ChuanqiXu added inline comments.Jun 25 2023, 7:02 PM
clang/include/clang/Basic/DiagnosticSemaKinds.td
11275–11278

According to #[dcl.pre] in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2615r1.html, the export for explicit instantiation is also allowed.

clang/lib/Sema/SemaModule.cpp
831–832

nit

834

nit

836
845–846
847–848

nit

848–849

Given P2615R1 doesn't allow explicit-instantiation in export block too.

851

ditto

clang/test/CXX/temp/temp.explicit/p2-p2615r1.cpp
20

Let's add another case for explicit instantiation.

clang/test/Modules/merge-var-template-spec-cxx-modules.cppm
35–36

It should be good enough to remove the "export" in the template specialization.

clang/test/Modules/pr59780.cppm
18–19

It should be good to remove the "export" in the template specialization.

clang/test/Modules/pr60890.cppm
21

The specialization is meaningful here to test the serializer/deserializer can handle the merge well. It is OK to remove the export here in this patch and I'll try to update the tests to make its semantics more clear.

clang/test/Modules/pr62796.cppm
42–43

In case it is not allowed to export the explicit instantiations, we should move it out of the export block instead of removing it.

clang/test/Modules/template-function-specialization.cpp
42

ditto

clang/unittests/Serialization/VarDeclConstantInitTest.cpp
89

Same as above, in this case we should move it instead of removing it.

118

We don't need this.

BTW, since this will break existing code. Let's mention this in ReleaseNotes.

iains added inline comments.Jun 26 2023, 6:36 AM
clang/lib/Sema/SemaModule.cpp
848–849

I think I must be missing something - I do not see that in the paper - please could you expand your comment?

ChuanqiXu added inline comments.Jun 26 2023, 7:04 PM
clang/lib/Sema/SemaModule.cpp
848–849

See the proposed change in #[module.interface]p1 in the paper, it changed:

export declaration

to

export named-declaration

And the change between the old declaration and the new named declaration is in the proposed change in #[dcl.pre]p1. So it shows the special declarations shouldn't be allowed after export.

Also I noted it is allowed to write export { declaration-seq_opt } where the declaration-seq may contain special declarations. It looks weird to me. I'll try to check it and ask WG21 when necessary.

ChuanqiXu added inline comments.Jun 26 2023, 7:08 PM
clang/lib/Sema/SemaModule.cpp
848–849

I checked the record. And it shows that the current wording reflects the intention. I mean

export template<> class A<int>;

is not allowed. But,

export { template<> class A<int> };

is allowed.

iains planned changes to this revision.Jun 26 2023, 11:36 PM

need to re-check that the intention of the paper is covered (since we currently treat bare 'export' and 'export {}' in a similar manner).

clang/lib/Sema/SemaModule.cpp
848–849

See the proposed change in #[module.interface]p1 in the paper, it changed:

...

And the change between the old declaration and the new named declaration is in the proposed change in #[dcl.pre]p1. So it shows the special declarations shouldn't be allowed after export.

Also I noted it is allowed to write export { declaration-seq_opt } where the declaration-seq may contain special declarations. It looks weird to me. I'll try to check it and ask WG21 when necessary.

Indeed that does seem to be a strange mismatch - but you are right the introduction does mention this:

"This paper addresses CWG2443 by forbidding applying export directly to certain meaningless declarations. Conversely, it also allows all kinds to appear with export {}. For consistency extern "C" is given the same restrictions when used directly."

so I think I need to recheck this patch.