Thanks for the review!

Test failures seem related to recent driver changes. There's a commit 6a8a423c1864ced060a7041bf6ada7574f35ad4d that purports to fix them.

• Use .copy() like the other nearby code

The new test checks how tightly things were packed across a stack of packs, pushed and popped. :)

@mikerice Alright, it turns out that PragmaPackAlignStorage isn't suitable for this (actually, I'm not sure what it _is_
suitable for) because it's deleted by the time the template gets parsed again.

While this fixes the assertion failure and the immediate issue of whether packing _works_ inside delay-parsed templates in a PCH, it does reveal a follow-on issue that I can't quite trace out.

This is a fix for https://github.com/llvm/llvm-project/issues/60543.

In D138453#4105209, @shafik wrote:

It looks like https://github.com/llvm/llvm-project/issues/60543 is hitting your added llvm_unreachable("missing serialization code for annotation token"); is this expected.

Fixed corrupted patch. I know that the -str test case is not the _ideal_ location for the comdat test, but it is the only test whose invariants failed (the IR for the descriptor definition now contains comdat, align 4).

This change caused a test to fail, so I took the opportunity to augment the test with COMDAT entry.

This looks great, and takes up the parts of my patch that I cared about. Thank you for doing this.
My primary concern is that the patch includes my "early init" changes -- while I support it and think it's the right solution, especially where it reduces double indirection on class pointers, there may be issues left to iron out.

This looks good to me, but I don't have a strong understanding of "outlining."

In D47233#1129207, @rjmccall wrote:

In D47233#1129110, @smeenai wrote:

WinObjC does this wrapping, for example.

I see. The idea of creating the type descriptors and mangled names ad-hoc for the catchable-types array is clever, and it's nice that the ABI is defined in a way that makes that work. (Expensive, but hey, it's the exceptions path.)

This largely matches what we've done in the WinObjC clang patchset here, with the critical exception that we've chosen to mangle the EH names as though they were for structs named after their classes.

Hi! Is there anything else holding up this patch? Thanks!

I've fixed the test to check the LLVM IR; I chose to use CHECK-SAME and use indentation to clarify what was going on. We're now checking that an empty protocol is emitted in full, and that all of its members match our expectations.

It seems more fragile to check the contents of the protocol rather than the invariant we care most about (its size).
I'm willing to do that, and am updating the patch accordingly, but I don't want to commit to a more fragile test than is necessary.
Illustratively, if the GNUstep runtime one day chooses to emit empty v3 protocols as {3, null, null, null, null, null, null, null} (which it may want to do to avoid emitting empty method lists, and which seems to work at runtime), a test capturing the body of the protocol will fail.

Thanks! I don't have the means to check this in myself.

Added a test per @rjmccall's suggestion. I chose to test this by emitting assembly because the llvm ir is significantly harder to pick apart for the true _size_ of the protocol.

Switched from i686-windows to i686-unknown-windows-msvc as per @compnerd's suggestion.
Based on the prior discussion around MSVC's definition of va_{start,end,arg} and how it is not a valid implementation that we do not pattern-match and convert into the intrinsid, I do not see the need in implementing an MSVC va_start test.

Thank you for the review! I don't have the means to check this in myself.

@compnerd CL warns for __forceinline variadics in C code as well:

In D44646#1042347, @efriedma wrote:

The compiler shouldn't inline functions which call va_start, whether or not they're marked always_inline. That should work correctly, I think, at least on trunk. (See https://reviews.llvm.org/D42556 .)

If you want to warn anyway, that's okay.

Ran clang-format over changed lines. Reuploaded diff with full context.

Fixed formatting.

Apologies if I've chosen the wrong set of reviewers.

Backed out changes to block type assignment.

Moved files around slightly.

In D44580#1040540, @lebedev.ri wrote:

Why not test/SemaObjC/block_compare.mm ?