Wow, thanks for the quick and thoughtful response @jhenderson ! This was awesome to wake up to!

If there are tests somewhere that I can add to, please point me to them! I'd love to add some tests, just couldn't quite find any (I'm guessing I'm just not looking in the right place... 😅)

@smeenai good idea on the third level!

Add a third level to ensure nontrivial structs within structs within structs works (this suggests that N embeddings works too). Also change the invocation of the test

@smeenai please feel free add any reviewers that I might've missed

I forgot to add the test originally, this update contains a test and updates to old tests to make them pass

@lebedev.ri right, sorry about that- I prematurely diff'd (got a few terminals crossed and thought I was finished with the test already). I will be amending with a test and a few other test fixes shortly. Sorry about the miscommunication :/

@steveire can you land this for me? I don't have commit access

Also, I don't have commit access. Could someone else commit this for me?

@dexonsmith Here are my results after passing those extra flags with -O3 (/Users/danzimm/oss/build/bin/clang -cc1 -internal-isystem /Users/danzimm/oss/build/lib/clang/6.0.0/include -nostdsysteminc -triple x86_64-apple-macosx10.12.0 -emit-llvm -disable-llvm-passes -O3 -fblocks -fobjc-arc -fobjc-runtime-has-weak -std=c++11 -mllvm -debug-pass=Executions -o ~/foo.ll /Users/danzimm/oss/llvm/tools/clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm):

Pass Arguments:  -tti
Target Transform Information
  FunctionPass Manager
Pass Arguments:  -tti
Target Transform Information
  ModulePass Manager
    Print Module IR
[2017-12-14 09:47:12.252472000] 0x7f87b90016f0   Executing Pass 'Print Module IR' on Module '/Users/danzimm/oss/llvm/tools/clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm'...
[2017-12-14 09:47:12.254702000] 0x7f87b90016f0    Freeing Pass 'Print Module IR' on Module '/Users/danzimm/oss/llvm/tools/clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm'...
Pass Arguments:  -tti
Target Transform Information
  ModulePass Manager

and with -O0 (/Users/danzimm/oss/build/bin/clang -cc1 -internal-isystem /Users/danzimm/oss/build/lib/clang/6.0.0/include -nostdsysteminc -triple x86_64-apple-macosx10.12.0 -emit-llvm -disable-llvm-passes -O0 -fblocks -fobjc-arc -fobjc-runtime-has-weak -std=c++11 -mllvm -debug-pass=Executions -o ~/foo.ll /Users/danzimm/oss/llvm/tools/clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm):

Pass Arguments:  -tti
Target Transform Information
  FunctionPass Manager
Pass Arguments:  -tti
Target Transform Information
  ModulePass Manager
    Print Module IR
[2017-12-14 09:47:20.884147000] 0x7ff71ed097d0   Executing Pass 'Print Module IR' on Module '/Users/danzimm/oss/llvm/tools/clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm'...
[2017-12-14 09:47:20.886182000] 0x7ff71ed097d0    Freeing Pass 'Print Module IR' on Module '/Users/danzimm/oss/llvm/tools/clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm'...
Pass Arguments:  -tti
Target Transform Information
  ModulePass Manager

Remove unnecessary checks from tests (sorry for unbatched updates)

Pass -disable-llvm-passes with -O3 so that we can test that the IR we generate actually is generated

I just dug into how the ARC optimization pass is invoked... it really shouldn't be invoked if -disable-llvm-passes is passed (or -disable-llvm-optzns which appears to just alias the first). Can you verify that my command is sane:

In D41050#954668, @rjmccall wrote:

In D41050#953917, @danzimm wrote:

Change tests to use non-O2 generated IR. It looks like the combined objc_retainAutoreleasedReturnValue/objc_autoreleaseReturnValue calls annihilate each other and we just get a call/ret.

Is that really happening at -O0? Maybe you need to add -disable-llvm-optzns to the test line if so.

Ah, just found test/Transforms/ObjCARC/rv.ll test3:

; Delete a redundant retainRV,autoreleaseRV when forwaring a call result
; directly to a return value.

Change tests to use non-O2 generated IR. It looks like the combined objc_retainAutoreleasedReturnValue/objc_autoreleaseReturnValue calls annihilate each other and we just get a call/ret.

Remove unnecessary change of braces

@rjmccall aha, right - thanks for explaining that to me (sorry for the bad logic I had earlier).

Call objc_retainAutoreleasedReturnValue after invoking a wrapped lambda

Or do we need to abide by those semantics strictly here? Could you expand on why that is, if that's the case?

@rjmccall ah right, good point -- I think it's ok to elide that objc_retainAutoreleasedReturnValue/objc_autoreleaseReturnValue pair in this case though, since all of this is generated within clang itself (and thus we can make the guarentee that the object will properly live until the return of the enclosing block) -- it reduces retain count churn this way too