LGTM. Thanks!

LGTM. Thanks for taking care of this.

In D143410#4107862, @DHowett-MSFT wrote:

While this fixes the assertion failure and the immediate issue of whether packing _works_ inside delay-parsed templates in a PCH, it does reveal a follow-on issue that I can't quite trace out.

c++
template <typename T>
void foo() {
#pragma pack(push, 1)
#pragma pack(show)
#pragma pack(pop)
}

results in...

unterminated '#pragma pack (push, ...)' at end of file

In D138453#4106666, @aaron.ballman wrote:

In D138453#4105211, @DHowett-MSFT wrote:

LGTM too.

ping, anything else needed for this?

Bump the AST version.
Add an entry to the release notes.

In D137570#3921879, @erichkeane wrote:

I haven't dealt much with the loop hint attributes, but two of my coworkers have done extensive work in our downstream (@jyu2 and @mikerice), and likely have feedback about how this affects downstream feedback.

Use underscore as count separator.

Rebase and update for new location of the OffloadEntriesInfoManager.

In D134816#3905301, @jsjodin wrote:

The cleanup and migration patches are in now. We can proceed with this improvement. @mikerice are you going to work on this, or did you want me to?

In D136601#3892410, @jsjodin wrote:

When I have a fix, is there a way for me to test my code on the buildbot? I don't seem to be able to reproduce the problem on my machine.

In D134816#3860950, @jsjodin wrote:

> I think it makes sense to do your cleanup first, then migrate to OMPIRbuilder, and do this feature improvement last. That way we have parity first then extend the functionality.

In D134816#3859003, @ABataev wrote:

Did you try to call SM.getPresumedLoc(Loc, false); in getTargetEntryUniqueInfo instead?

rebase

Add a default constructor and use emplace_back in a couple places.

Fix formatting.

Added uses in static member functions to tests.

In D131222#3708805, @ABataev wrote:

In D131222#3708112, @mikerice wrote:

To include static data members in the message and be correct in C or C++ we need three cases:

In C:
expected variable of type 'omp_interop_t'

In a C++ non-member function:
expected variable or static data member of type 'omp_interop_t'

In a C++ member function:
expected variable, static data member, or non-static data member of current class of type 'omp_interop_t'

This seems to exactly describe the situation to me. Maybe I am missing the point.
Feel free to make specific recommendations to help move this along.

You can’t use non-static member functions in static member function.

To include static data members in the message and be correct in C or C++ we need three cases:

Changed message to match old message. Prints 'variable' or 'data member' depending on context.

Added optional type to diagnostic given in getPrivateItem().

Use getPrivateItem() for interop variables.

In D131222#3701678, @ABataev wrote:

Is it allowed to be a field per OpenMP standard?

In D126331#3538670, @jdoerfert wrote:

Cool! Can we have that for begin declare variant too :D ?

Add a function to parse reserved locators.

Thanks for the review @ABataev. Any more comments on this update?

Use dependency kind to represent 'omp_all_memory' which fits nicely for codegen.
Add struct to OMPDependClause to reduce parameter passing.
Move OpenMPVarListDataTy so it can be shared between parsing and sema to reduce parameters in calls.

Added the source location of 'omp_all_memory' to the clause.

Return Decl only when a single Decl.
Test that error is still given if multiple Decls.