Thanks, LGTM :)

Cunning, I like it :)

Thanks, this looks great.

@rjmccall Do you have any more comments?

Mostly looks good, other than the regression in enum parsing.

Looks good to me.

Thanks for the refactoring :)

Could we perhaps rename these flags to e.g. -static-libsan (with a -static-libasan alias for compatibility)? It seems confusing that the way to enable a static tsan runtime would be with -static-libasan.

In D38473#888159, @mppf wrote:

You should also indicate *which* record layout (complete object type or base subobject type) the field number is for. I don't think there's any guarantee that the same indexes work in both.

I added a comment about this - indicating that inherited fields are not supported by this function. My use case is just for C structs at the moment and I'm not actually sure what we'd need to do for the interface to support building GEPs for inherited fields. I'm sure it would complicate the API. I think we should leave that complexity to another function or a future function (when somebody actually needs it).

I have no philosophical objection to exposing this, but defer to @rjmccall on that. As is usual with our C++ API, there's no guarantee that we will keep this working in future versions. (Eg, if we move to an IR representation using something non-GEPable to represent a source-level class type, we would remove this function as it would be meaningless.)

LGTM, thank you!

This looks fine to me too, assuming the other parts get approved.

In D35216#856415, @NoQ wrote:

We already have the object's fields in the AST, with its AST record layout, however field names and layouts are implementation-dependent, and it is unsafe to try to understand how the specific standard library implementation's layout works and what specific private fields we see in the AST mean.

A couple of remaining pieces that I think are missing:

I wonder whether this feature really pulls its weight compared to using @file and prepending -fmodule-file= to each line.

In D37881#871556, @vsapsai wrote:

I don't like name SavePendingDelayedStateRAII as too vague. Hope you'll be able to suggest something better or I'll have better ideas later.

dlj and I discussed this offline somewhat, and dlj made the interesting point that using ADL *at all* within the implementation of the standard library brings with it the risk that your implementation will not function correctly if a user-declared operator could be at least as good a match as your intended callee.

LGTM

In D37436#869851, @hfinkel wrote:

A large fraction of the number of attributes we'll want to use are going to fall into this category (because Clang doesn't have its own attributes, but copied GCC's, for many things). I don't think we'll get good implementation feedback until we have this figured out. If we can't sync with GCC soon, I suggest just making a reasonable guess. My first choice would be to just allowing everything, and then we can see what people found to be useful and why. Our experience here can also provide feedback to GCC (and we can always update late if needed - it is still an experimental feature).

If this is just supposed to be an experiment to get feedback on the feature, then I don't think we should be treating it as a different attribute syntax at all. Rather, I think we just want to permit C++11 attributes to be parsed in other language modes. If/when this becomes part of some future C working draft, I think that's the time to have a separate attribute syntax with a distinct set of valid unqualified attribute names.

decltype(auto) lambda = []{}; and decltype(auto) list = {0,1}; seem like very different situations to me; in the latter case, the initializer is not even an expression.

Accepting this under -std=c2x is premature. We don't even know whether there will be such a standard yet, and this has not been voted into a working draft. But the -f flag form is OK.

Looks good to me, but I'd like EricWF to also review.

Part of this change (marking the coroutines TS as "Clang 5") is already done, and we will change all the class="svn" entries on this page to class="full" when Clang 5 releases (we keep them in the yellow "SVN" color until they're in a released version of Clang).

It's not reasonable for external users of Clang's AST to infer deep meaning from the "invalid" flag. It's simply a mechanism by which we (a) limit the amount of follow-on diagnostics, and (b) somewhat weaken our AST invariants in the presence of invalid code; it is an implementation detail and subject to change at any time. (If a node is not marked invalid, that does not imply the corresponding source code is valid.)

The CXXStdInitializerListExpr node has pretty simple evaluation semantics: it takes a glvalue array expression, and constructs a std::initializer_list<T> from it as if by filling in the two members with a pointer to the array and either the size of the array or a pointer to its end. Can we not model those semantics directly here?

In D37042#855713, @efriedma wrote:

I didn't think of this earlier, but strictly speaking, I think "(char*)nullptr+0" isn't undefined in C++?

In D36527#854600, @rsmith wrote:

We'll also need to agree within the cxx-abi-dev list how to mangle lambda closure types for this form

This patch appears to be missing some necessary changes in the following places: