The right way to produce diagnostics under pedantic mode is to model them as Extension or ExtWarn in the .td file, not by checking the Pedantic diagnostic option directly. If this is an intentional GNU extension too, that makes things a bit more complex (one approach would be to have two diagnostics, one for "this is ill-formed" and another for "this is a GNU extension").

I think the check is wrong here. We need this clear call to reinitialize the object after moving from it. Maybe that function should be annotated as reinitializing the object instead?

We don't want to allocate storage for the lambda fields for non-lambda classes, which is why we use distinct base classes. Is the problem you're trying to solve here that we fake a definition in AST deserialization before we know whether the class is a lambda? If so, that seems solvable by moving the IsLambda flag out of DefinitionData into CXXRecordData (perhaps as a distinct TagTypeKind?).

In D52137#1236065, @Quuxplusone wrote:

In D52137#1236053, @rsmith wrote:

I think we can and should do better about false positives here. If you move this check to SemaChecking, you can produce the warning in a context where you know what the final type is -- I don't think there's any reason to warn if the final type is signed and no wider than the promoted type of the negation.

I share your general concern about false positives, but in the specific case you mentioned—

void use(int16_t x)
uint8_t u8 = 1;
use(-u8);

—I think it'd be surprising to maybe 50% of average programmers that x's received value wasn't int16_t(255) but rather int16_t(-1).

I think we can and should do better about false positives here. If you move this check to SemaChecking, you can produce the warning in a context where you know what the final type is -- I don't think there's any reason to warn if the final type is signed and no wider than the promoted type of the negation.

Looks good other than the warning, which I don't yet understand.

In D51789#1235100, @ldionne wrote:

In D51789#1235096, @rsmith wrote:

OK, so the semantics of this attribute are "explicit instantiation declarations or definitions applied to the enclosing class do not apply to this member", right? So it opts the member out of both extern template and (non-extern) template, but only when applied to an enclosing class.

Yes, but it also (obviously) opts the member out when applied to the member itself, not only to an enclosing class.

In D51789#1234903, @ldionne wrote:

I think now's a good time to bikeshed the name of the attribute if you have other suggestions.

Thank you!

In D51463#1223631, @erik.pilkington wrote:

I think there may be some more (many?) similar bugs to this. Possible testcase: _Z1fI1SEiS0_T_ and _Z1fI1SEiS0_S0_. I think these will be considered equivalent to the canonicalizer because their representation is structurally equivalent, but they are in fact distinct.

Looks good (with a couple of minor code style adjustments). Do you need someone to commit this for you?

Thanks, some comments but the approach here looks great.

In D51246#1219437, @davidxl wrote:

Perhaps add some test cases for the parser and reader?

Add tests and extend file comment to give an example of <encoding>.

I'm not a fan of the duplication introduced here, but the new code is definitely more obvious. On balance, this seems like a small improvement, so let's go for it.

It'd be good to test that [[no_extern_template]] affects instantiation, not just code generation (eg, put something in the body of the entity that will trigger an error if instantiated, and check that the diagnostic is produced at the right times).

Fixed in r341499.