Thanks, committed in r313929.

Address review comments.

Use DISPATCH_NOESCAPE instead of "attribute((noescape))".

In D38141#877824, @kubamracek wrote:

That's what we should do here. Since the file includes dispatch.h, we should be able to just use the DISPATCH_NOESCAPE macro, which already uses #if __has_attribute.

In D38141#877782, @kubamracek wrote:

What happens when building this code with a compiler that doesn't understand __attribute__((__noescape__))? Is it just ignored?

I think this is correct.

Upload the rebased patch again.

Reopening this review. I accidentally closed this review when I committed r313717 (the patch that adds support for 'noescape').

This one can be closed.

Reopening this review. I accidentally closed this review when I committed r313717 (the patch that adds support for 'noescape').

ping

Address review comments.

Rebase.

I see. It looks like there is an ambiguity between 'new_anotation' and 'new_annotations' that can't be resolved in ActOnMemberAccessExpr because they have the same distance from 'new_annotation'. This doesn't happen if the full expression (new_annotation->Swap) is typo-corrected because 'new_anotation' will be the only valid choice in that case.

I was thinking about correcting the typo in Sema::ActOnMemberAccessExpr before checking whether Base is dependent. Doing so would cause BuildMemberReferenceExpr to be called instead of ActOnDependentMemberExpr.

LGTM

Address review comments.

Is it possible to avoid creating CXXDependentScopeMemberExpr in the first place? It seems to me that we shouldn't be creating a CXXDependentScopeMemberExpr for an ObjC property access.

clang currently rejects "void foo(int = a);" and so does gcc.

In D36915#849622, @faisalv wrote:

I don't think this approach is entirely correct for at least the following reasons:

1. in the lambda case the machinery that diagnoses capture failures should be the machinery erroring on the lambda (when the parameter is odr-used)

In D36915#849622, @faisalv wrote:

I don't think this approach is entirely correct for at least the following reasons:

1. in the lambda case the machinery that diagnoses capture failures should be the machinery erroring on the lambda (when the parameter is odr-used)
2. in the unevaluated case, once you disable the error, the instantiation machinery will fail to find the corresponding instantiated parmvardecl.

Test access to protected member functions.

Address review comments.

Include noescape attribute information in the function prototype and modify the AST printer and name mangling accordingly.

In D35693#816994, @rjmccall wrote:

Does the ARM64 ABI call for unwind tables to be emitted for all functions, like the x86-64 ABI does?

Anyway, it seems pretty unfortunate that the default behavior breaks exceptions.

Address review comments.

In D32210#810508, @rjmccall wrote:

In D32210#810292, @ahatanak wrote:

Address review comments.

• Allow attaching "noescape" to pointers other than block pointers. Update the docs accordingly.
• Attach attribute "nocapture" to parameters that are annotated with "noescape".
• Call Sema::isValidPointerAttrType to determine whether "noescape" can be applied to a parameter. Also, use the existing warning "warn_attribute_pointers_only" rather than defining a new warning that will be used just for noescape.
  
  I also thought about what else we can do in the front-end when a parameter has 'noescape". One idea is to do something similar to what r301667 did and omit emitting retains and releases of block captures when the block is passed to a function taking a noescape parameter. If that is viable, I can look into it after committing this patch.

Hmm. Unfortunately, I'm not sure that's valid. The retains and releases of block captures don't protect against anything related to escaping the block; they protect against the original variables being modified during the lifetime of the block. It is true that a block literal passed to a noescape parameter has a shorter effective lifetime — we know for certain that it will be unused after the call, and ARC only promises that a value in an imprecise-lifetime strong variable like a block capture will be valid until the last load of that value from the variable. But that duration is still long enough for someone to modify the original variable in a way that is properly sequenced after the formation of the block.

Now, if you could prove that the variable was not modified for the duration of the call, that would be sufficient. And that would be easy to do in the common case by just proving that the address of the variable never escapes. Unfortunately, we don't have that information readily available because Sema doesn't collect it.

Address review comments.

Address review comments.

Define and use CXXMethodDecl::getDevirtualizedMethod, which returns the function that is called when a call is devirtualized.

Address review comments.

Does r307218 unbreak the tests?

I tried compiling test18 with gcc7.1 (https://godbolt.org) and it fails to compile test18 with "inconsistent operand constraints in an 'asm'". Am I using the same version of the compiler as yours?

I'm not exactly sure why the test failed, but the patch was reverted in r306859.

Set Micro to 99 too.

Address review comments.

I'll revert the changes I made to libc++ that annotates the allocation functions with availability later.

The updated patch produces diagnostics if an aligned allocation function is selected that is not implemented in the c++ standard library of the deployment target (except when the function is defined by the user and its definition is available).

Duncan and I had a discussion on this.

This looks correct to me. The commit log of the original commit (r163266) doesn't say that CFIndex has been dropped intentionally, so this should be fine.

Fix line number and remove #else.

I suppose it's possible to define a new driver option that can be used to tell clang to annotate the implicit declarations with an availability attribute, which will enable the link time error to be caught at compile time. Alternatively, it's also possible to put the availability attributes by default and use the driver option to remove the attributes, but this will cause clang to error out on a valid code when the users have provided their own implementations of the aligned operators.