There is one place where there is an ambiguity in the specification:
given a base type !{!"whatever", !N, i64 1} there is no way to tell if
this is a struct containing !N at offset i64 1 or a scalar immutable
TBAA node with !N as the parent. Right now I interpret this as the
former (as the implementation has been doing for 3 years). I will fix
the specification in a forthcoming documentation patch.

LGTM.

Nice clean up!

LGTM.

In this testing case, the first clang invocation builds a system module X and a non-system module Y (X imports Y). At the second clang invocation, the parent thread validates the existing module X and module Y. Because X is a system module, we don't diagnose the differences in diagnostic options. When building module Z in the child thread, since Z is not a system module, we will spot the diagnostic differences and invalidate module Y. But the parent thread will continue accessing the deleted FileEntry for module Y.

Thanks Richard for the testing case. It is also obvious from the testing case that we can have another diagnostic in flight when emitting err_fe_pch_file_modified.

It makes sense to rebuild the expression when a field designator stores a FieldDecl.

Thanks a lot for the pointers!

This is better than what I asked for :]

LGTM.

Cheers,
Manman

LGTM.

Nice cleanup! Thanks for working on this,

This is a nice cleanup!

Thanks for working on this!
Manman

LGTM. Please update the comment.

Thanks for working on this!

Hi Doug,

This patch is now much simpler with the updated version of D23079.

Address Doug's comment. ObjCTypeParamType is a non-canonical type now, it is canonicalized to the underlying type with protocol qualifiers.

In D23858#525647, @rsmith wrote:

It seems to me like this is papering over an issue rather than fixing it.

Thanks for reviewing!

I will update this patch once the 2nd patch is done.

Cheers,

Thanks,

Are you okay with the patch now?

LGTM.

The fix looks reasonable to me.

This is done so containers, such as vector<partially_available> can be used safely provided partially_available is safe at the point of instantiation. I think the way to improve this is in Sema::getVersionForDecl(). There we could look at function and template parameters to determine the best base version, then diagnose against it.

Addressing Richard's comments.

This looks pretty good. Can you add a few more testing cases for templates such as @available inside the template function, @available enclosing the template instantiation?

Thanks,
Manman

Addressing Richard's comments.

In D23125#510632, @rsmith wrote:

This doesn't seem like quite the right user interface for this feature. The module cache is volatile, and it's not really reasonable for people to assume they know what is and isn't within it. Instead, it seems like what we want to provide is zero or more paths to directories containing prebuilt .pcm files whose file names are the same as their top-level module names, completely separate from the module cache.

Specifically, rather than spelling this as -fmodules-use-prebuilt-modules -fmodules-cache-path=X, I'd suggest spelling it as -fprebuilt-module-path=X or similar (which can be repeated to provide multiple search paths). That would then combine orthogonally with -fno-implicit-modules and -fno-implicit-module-maps, where implicit modules would still use the module cache. Does that make sense for your use case?

In D23125#504942, @benlangmuir wrote:

How about -fmodules-use-prebuilt-module-cache for the flag name? Saying "prebuilt-modules" is confusing to me, since -fmodule-file can also be used to load a prebuilt module, but doesn't use a cache.

Add comments for setting IsSystem to true.

Thanks,
Manman

Hi Erik,

Yes, this still looks good to me. Please commit.

Abandon this change for now.

Addressing Ben's comments

In D22773#495524, @benlangmuir wrote:

the pcm could still be rewritten by a compilation that doesn't use a PCH, and then it would be out of date because of the timestamp instead of the diagnostic options

"a compilation that doesn't use a PCH", is that a different project? And we have two projects building in parallel? Just to make sure I understand.

Two different projects (or targets, or whatever), but they don't even have to build at the same time. They just have to share a cache. Suppose you have a project A with a PCH and -fmodules-disable-diagnostic-validation. Suppose you have another project B that does not use this flag, and does not have a PCH. With this patch, A and B can share a module cache.

A builds a PCH that depends on some module X -- OK
B builds with -Werror. Rebuilds X.pcm -- OK

Now suppose we build A again because of some change: it can't build because X.pcm changed, but we haven't rebuilt the PCH.

In D22773#495403, @benlangmuir wrote:

We need to add this option to the module hash (see getModuleHash - we already add a bunch of other HSOpts there). Otherwise the pcm could still be rewritten by a compilation that doesn't use a PCH, and then it would be out of date because of the timestamp instead of the diagnostic options.

LGTM except one nit.

In D22636#493072, @benlangmuir wrote:

Can you point me to the source codes where we use rename to replace the file? I am curious on how this all works out.

This is the same as clang's handling of other output files. See {{CompilerInstance::createOutputFile}} and {{clearOutputFiles}}. When we are performing the GenerateModuleAction, the .pcm file will be the output file.

LGTM.

In D22636#491679, @benlangmuir wrote:

B.pcm becomes out of date when we try to load module "A", because another instance overwrites "B.pcm"

How can this happen? We intentionally keep the file descriptors of modules open. If you just built A, then you will have B.pcm still open. When you read A, you will use the same B that you used when you built A even if the file on disk has been replaced (and we use rename to replace the file, so the existing one is never modified).

LGTM.

LGTM.

LGTM.

In D22270#483027, @spyffe wrote:

Thank you very much for your review, Manman! I can implement all your individual fixes, those look fine. In answer to two of your bigger questions, though:

• I see what you mean about the definition of an anonymous structure. It looks like our structure is an untagged structure, not an anonymous one. That said, this change is safe for all the places that use this function, so it may be appropriate to change the name to findAnonymousStructOrUnionIndex. What do you think?

Sounds good!

• The test case is unfortunately only an approximation to the more complicated behavior that occurs in lldb. The difference is that the testing infrastructure inside Clang does not implement an ExternalASTSource, which LLDB does. As a result, I've used the test case to verify that we don't break parsing by making this change.

Ok, thanks for the explanation!

I am not sure if we should handle this inside findAnonymousStructOrUnionIndex. Here is the definition of anonymous structure I found: An unnamed member whose type specifier is a structure specifier with no tag is called an anonymous structure.

Before this patch, the testcase added used to take
5s to compile!!! A bit more elaborate NSDictionary literal with some
undeclared enums would make the compiler take 22min to run, followed by a crash.

--> this is a big improvement!

In r268091.

LGTM.

Thanks for working on this, Erik.

In D21295#474241, @Anastasia wrote:

LGTM!

Has this test case been missing from the original commit? If yes, could you point to it please! Thanks!

LGTM.

Use getLocForEndOfToken to insert fix-it after a type name instead of setting DeclSpec's range end.

In D20844#445762, @rjmccall wrote:

Hmm. No, I think the original code is correct here — RangeEnd is a token range, and those are generally inclusive rather than exclusive. The fix-it needs to be inserting at the end of the token.

In D20843#445756, @rjmccall wrote:

Oh sure, because we don't strip the original type if there isn't a conflict. LGTM.

In D20383#443613, @doug.gregor wrote:

Yeah, this looks like the right approach. PCH follows the same rules as modules when it comes to newer information shadowing imported information.

Doug and Richard,

Thanks Bruno

After r231508 made changes to promote constant temporaries to globals, the assert fires when a std::initializer_list is constructed using Objective-C string literals.

Addressing review comments from Doug and Adrian.

Thanks for reviewing the patch!

In D19005#398881, @MatzeB wrote:

In D19005#398802, @manmanren wrote:

Some general comments:

LGTM.

Some general comments:
Is this NFC (no functionality change)? I noticed a small testing case change.

Cheers,
Manman