Please update cxx_status.html to mark P1771R1 as implemented in SVN.

Well, this restores an incorrect behaviour: we're not permitted to substitute into the initializer of the variable template here.

In D64799#1589557, @ilya-biryukov wrote:

I tried to find a good place to emit unresolved typos earlier (to make sure CodeGen does not ever get TypoExpr), but couldn't find one.
Please let me know if there's some obvious place I'm missing.

I don't think this problem really has anything to do with statement expressions; consider:

C++20 designated initializers don't permit mixing designated fields with non-designated ones, so some of the examples here are invalid. However, I think we should be looking for an attribute design that works well in both C and C++, and with the various Clang extensions that permit the full generality of C designated initializers in other language modes. I also think this patch is combining multiple features that would be useful to expose separately. To that end, I think something like this might make sense:

LGTM, thanks!

Do you have commit access or do you need someone to commit this for you?

LG with a few tweaks.

• Replace #defines of field names in non-[[no_unique_address]] mode with accessor functions

In D63744#1561087, @ldionne wrote:

I like this, however I want to echo @EricWF 's concern about the conditional compilation this introduces. Do we get any benefit if we still use compressed_pair but switch THAT to use no_unique_address instead?

Thanks, this looks good; just some nits.

Patch generally looks good; just a minor concern about the output format.

PPCallbacks seems to be missing the addition of EnteredSubmodule and LeftSubmodule; PPChainedCallbacks seems to be missing the addition of LeftSubmodule.

• Rename __hash_ macro to avoid name collision.

• Address a couple of review comments from Marshall.

• Revert one more vestigial change.

• Revert vestigial changes to __compressed_pair.

In D63637#1553781, @rnk wrote:

I think maybe we shouldn't build libc++, and any other shared libraries that might conflict with system shared libraries, into ${builddir}/lib.

Thanks! Minor comment then feel free to commit.

In D63451#1549563, @rjmccall wrote:

Can this attribute not be applied to a base class, or to a type?

• Use custom code to specify CXXABI requirements on attributes.
• Remove dead code that would have handled [[no_unique_address]] in C.
• Extend documentation to include an example and to mention that this is a standard C++ attribute.

In D63574#1551933, @mclow.lists wrote:

In D63574#1551251, @mclow.lists wrote:

How many of these should fail?

Turns out that only the first one should fail - and that's the one that clang rejects.

Perhaps we should rewrite all #if-like directives to #if 0 or #if 1? Either that or we could emit pragmas indicating the values of later __has_includes. Special-casing macros of this specific form is at best a partial solution.

• Remove accidentally-added file

• Address review comments from @AaronBallman.

I think we can maybe make this a little more convenient to use. For the non-JSON -ast-dump format, I added utils/make-ast-dump-check.sh which can be used as (for example):

In D57086#1546386, @aaron.ballman wrote:

In D57086#1535873, @domdom wrote:

Something I should ask, it seems like GCC only ignores the NullStmts at the end if it's in C mode. Should clang match this behaviour exactly?

I can't think of a reason that this should only happen in C mode, can you @rsmith?

• Address additional review comments from rjmccall.

• Fix somewhat-incorrect comment on Size member.

• Address review comments from rjmccall.

Nice cleanup!

In D63371#1546500, @rjmccall wrote:

Isn't [[no_unique_address]] only significant for empty members? I'm not sure why they need significant support from constant-building, since they expand to no meaningful initializer.