Sorry, I didn't mean to accept this yet. I think this is something that is better fixed in Sema.

Sorry, I was misunderstanding the problem.

I think the root of the problem is that BlockDecl knows the captured variable but doesn't know the type of the capture. The type of the variable and the type of the capture can be different if the block is nested inside a lambda or another block, which is why CI.hasCopyExpr() can return a non-null value when VT is a lvalue reference:

The code is crashing here because the loop in computeBlockInfo is trying to capture a variable that is captured by reference by the enclosing lambda as if it were captured by value. This is the type of VT:

Improve diagnostic messages.

LGTM

Make sure that volatile trivial fields in a struct don't cause Sema to emit a diagnostic. Simplify the code in Sema::ActOnFields .

This patch is unnecessarily complicated and is not correct.

Add a note diagnostic to inform the user of the reason for not allowing annotating a class with trivial_abi.

Add a test case for an anonymous struct nested inside an anonymous union.

Address review comments.

LGTM with one minor nit.

In D55662#1349329, @rjmccall wrote:

Oh, and please update the commit message to primarily talk about the changes to placeholder checking. You can discuss the impact on the repeated-use-of-weak warning in a follow-up paragraph.

Pass Init by reference and use the rewritten expression returned in it to perform variable initialization. Add a test case that tests new expression with auto types.

We should probably check that alignedAllocMinVersion returns the correct versions for other OSes too, but this patch is fine.

Make deduceVarTypeFromInitializer and DeduceVariableDeclarationType return the new initialization expression and use it in Sema::AddInitializerToDecl. Add a test case that tests lambda capture with an initializer.

We can make DeduceVariableDeclarationType return the rewritten expression and replace Init in Sema::AddInitializerToDecl with it.

In D55662#1346077, @rjmccall wrote:

Hmm. Are we resolving the placeholder expression twice here? That might be the basic problem.

I'm not sure whether this is something libc++ (as opposed to the compiler) should handle or not. I just wanted to understand what the expected behavior is first.

It seems like this patch causes clang to accept the following code when compiled with -std=c++11. Is this the expected behavior? Shouldn't the compiler reject the code if it's not compiled with -std=c++17 or newer?

In D55662#1346055, @rjmccall wrote:

I think you could just disable the diagnostic in an unevaluated context.

Do not record use of weak variables when the type of an auto variable is being deduced.

LGTM

Sorry for the delay. The updated patch replaces '@' with '\1' on all targets.

In D55662#1337141, @rjmccall wrote:

In D55662#1336835, @ahatanak wrote:

In D55662#1335773, @rjmccall wrote:

Okay. You may need to push an unevaluated context when doing that.

Since I'm just moving the call to CheckPlaceholderExpr to the call site, I don't think I have to push an unevaluated context there?

Hmm. Right, for the auto inference specifically it's fine because the expression is in fact evaluated: we're not just eliminating placeholders in order to resolve decltype, we're eliminating placeholders to actually figure out what's going on with the initialization.

Check whether the declaration passed to Sema::CanUseDecl is an aligned allocation/deallocation function that is unavailable.

In D55662#1335773, @rjmccall wrote:

Okay. You may need to push an unevaluated context when doing that.

Remove the call to CheckPlaceholderExpr in Sema::BuildDecltypeType and move it to Sema::DeduceAutoType. Assert that the expression that is passed to Sema::BuildDecltypeType isn't a placeholder.

Sorry, please ignore my previous comment. I was looking at the wrong place.

Here are a couple of examples I found running the regression tests:

Call CheckPlaceholderExpr instead of pushing an unevaluated evaluation context.

The patch looks largely fine to me.

Just to clarify, this patch doesn't change clang's handling of C++ unions that have non-static data members with non-trivial special member functions.

ping

LGTM

LGTM

I've reverted the changes I made to test/SemaCUDA/call-host-fn-from-device.cu since r342749 fixed the overload resolution bug.

In D54539#1298949, @rjmccall wrote:

This should not be changing the actual @-encoding value. If we want to use the @-encoding in the symbol name, we can change it when naming the symbol, provided that \1 is not legal in the @encoding.

http://wg21.link/p0968r0#2227 says:

LGTM