LGTM

clang marks the called function foo in p1.cpp as nounwind here: https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.cpp#L1284

Remove AddressImpl altogether.

I don't have a test case for this change because there is a bug that prevents using the maximum allowed alignment (see https://github.com/llvm/llvm-project/issues/60752).

Add triple to the test and add release note for the fix.

Fix type and add comment. Remove unnecessary cast.

@tahonermann @cor3ntin have you had a chance to take a look at the updated patch?

Add comment.

• Set the KnownNonNull bit correctly when Address::withAlignment is called.
• Pass NotKnownNonNull to the call to Addr.withPointer when the address of thread local storage is created.

Address review comments.

I agree that pushing an empty scope without initializing any of its members seems wrong.

Fix indentation.

Instead of pushing an empty lambda scope, switch to the enclosing context if the variable is used in a default argument expression of a lambda call operator.

@efriedma do you have any comments?

I'm still don't understand what the problem is about cleaning up the lambda scope.

Doesn't Sema::FunctionScopeRAII pop the lambda scope when it goes out of scope?

Pass a KnownNonNull_t flag to Address::withPointer.

Fix a few typos that were causing compile errors.

There are more places where we know contextually the pointer can't be null and can set the bit to KnownNonNull or set the bit of an LValue or Address using an existing Address's KnownNonNull bit.

Add a bit to Address and LValue that tracks whether the pointer is known not to be null.

I'm not familiar with the WinEH stuff, but the other parts (the code that adds bundles, etc.) LGTM.

In D136639#4006953, @rjmccall wrote:

Oh, I see. That's a really unfortunate way to end up emitting this code pattern, since ignoring the result is so common. To fix that, we'd have to either figure out the result was unused in Sema or do a relatively complex analysis in IRGen, though.

Check that the destructor is called conditionally.

I read the patches and review comments in https://reviews.llvm.org/D42776, but I don't remember why I added that assert. Maybe I was just trying to ensure the version number passed to getTemporary was the one that was used to create the temporary. For example, if a temporary was created using version X and later retrieved using version Y because of some bug in constant evaluation, the assertion would fail.

abc87ad4ed6cc5e6568751f375d1c646edb502f7 should fix the failing test.

Address review comments.

In D138796#3967899, @dexonsmith wrote:

In D138796#3957499, @ahatanak wrote:

I confirmed ARC optimizer hasn't removed the retain/release pairs in both functions at least since October 2017. The retain/release pair in @"\01-[Top0 _getX]" can be removed. I'm not sure about the one in @"\01-[A z]".

Great progress; seems to me like the regression is old enough it might not be an easy fix. Are you okay with the tests being cleaned up to reflect reality in the meantime?

Yes, I think that's okay. We are tracking this internally, so this can be committed as-is.

Add another environment variable CC_PRINT_HEADERS_FILTERING, which can be used to specify whether header information should be filtered or not.

I confirmed ARC optimizer hasn't removed the retain/release pairs in both functions at least since October 2017. The retain/release pair in @"\01-[Top0 _getX]" can be removed. I'm not sure about the one in @"\01-[A z]".

ARC optimizer was previously removing the retain/release pair, but it's not clear to me why it was safe to do so. There is a load that loads an ivar of the object before the call to @llvm.objc.release, so the object has to be kept alive at least until that point.

Address review comments. Also, change check string in test case to fix pre-merge checks that were failing.

In D137996#3927947, @jansvoboda11 wrote:

Mostly looks good. Is this expected to work with Clang modules at all?

Address review comments.

Probably not NFC according to https://llvm.org/docs/Lexicon.html, but LGTM.

LGTM with minor comments.

LGTM

LGTM

This LGTM for apple's runtime assuming it knows how to handle the new string.