Indeed. IIUC, here is no way clang-cl to load plugins if compiled BUILD_SHARED_LIB=0. It is not clear to me if that's a design limitation or something else. I'd love to be able to load plugins on a 'standard' clang-cl instance.

@chapuni, you have reverted this patch and the commit message says "investigating". Did you come to a conclusion? Can we reland it?

Is this change still relevant?

ping...

Ping...

@rsmith, @bruno could you verify this patch on your codebases?

Add parens.

It looks like the diagnostic options and few others were moved out from the control block in r297655 by Manman Ren. The header files are still part of the control block. The best I can do is buffer that information and print it out last. Is that what we want?

@rtrieu, your comment was along the lines of what I was thinking of. I have updated the patch. Without testing it on large scale, I the current change seems to work for us.

Remove the TypeMap

LGTM!

r332816.

Ok, that's great! Sorry for the delay and thanks for landing a similar patch. Btw, we should probably find a more terse way to test the ODRHash, eg. with unittests.

I am not sure if this is the right time but maybe testing and comparing the behavior of this patch against something such as the ODRHash will help you, me (and probably others) to understand the current patch better.

Add sanity check.

Reading back the patch, we are turning on the bindings by default ;)

Could you double-check if we can add this to an existing test? Would test/SemaCXX/pr25181-crash-on-invalid.cpp fit and potentially rename it.

ping...

ping2...

LGTM!

LGMT! We can rely on post-commit reviews for changes like this one.

LGTM!

Finer grained clang stats can be seen here.

Reduce further the deserializations from 451 to 449 by providing a more complete implementation of ODRHash::AddTemplateArgument.

Reduce hash collisions for template specializations.

+1 Thanks for working on this. Great to see this happening!

Reverse template specialization order.

Zero IsPartial and improve comments in assert and free text.

I have created a simple (-ish) benchmark targeted to stress test modules with a good number of template specializations. I use the mp11 library from boost. I am building two modules which contain around 1K specializations (mostly full specializations). The example can be found here. I use a small fraction of them. This patch deserializes (only) 1117 specializations for around 0.2 seconds whereas without it clang deserializes 1905 specializations for 0.4 s.

Loading of lazy partial template specializations should not trigger loading of full template specializations.

Address comments:

• Fix style;
• Do not potentially deserialize a specialization in debug mode.

Teach ASTReader::CompleteRedeclChain to load only the template specializations with the same template argument list.

Address inline comments: order the read operations.

Fixed a comment typo.

Thanks! Landed in r320763.

Fix preexisting comment typo.

For the record: relanded in r306903.

LGTM!

Reverted in r316153...

Revised patch landed in r316150.

I assume this would fix it:

Reverted in r316029 because the bots got angry at me:

Landed in r316025.

Address comments.

This patch can rely on a post commit review if necessary.

You should probably update the code creating the vfs before the call to createFileManager in lib/Frontend/FrontendAction.cpp.

Add a test case.

@bruno, what's the fate of this?

@rsmith ping...

ping...

Sorry, undo ping... we have a test case.

LGTM! I'd reword the commit message, saying that we intended to add a fast path in DeclContext::removeDecl which checks if the decl is hidden to avoid addition in the lookup tables. That caused problems with modules, because the modules system extends the definition of visibility and this is a test making sure we do not reintroduce such an issue.

ping...

LGTM +ping!

Landed in r311844.

A version of this landed in r311843. I am keeping in mind this discussion and I'd like to follow up with @rjmccall once I open the more major review item (libInterpreter).

Type& name -> Type &name.

std::string& -> llvm::StringRef.

Fix StringRef allocation.

And thanks for working on this!!

I do not feel qualified enough to review this patch but I added few minor comments.

We set the record's property denoting whether we can pass the decl by registers as a last step of Sema::CheckCompletedCXXClass. We cannot do it any earlier than that because we have not computed the triviality information.

Move back the triviality checks in CGCXXABI. Explain why.

Put back accidentally removed test case.

Address some of the comments.

Move the checks in Sema.

LGTM.

This LGTM but I'd like to hear from @lhames.

In D34444#818030, @rjmccall wrote:

In D34444#812836, @v.g.vassilev wrote:

In D34444#812418, @rjmccall wrote:

In D34444#795175, @v.g.vassilev wrote:

@rjmccall, thanks for the prompt and thorough reply.

In D34444#793311, @rjmccall wrote:

Okay. In that case, I see two problems, one major and one potentially major.

This is a very accurate diagnosis which took us 5 years to discover on an empirical basis ;)

You could've asked at any time. :)

True. I am not really sure I knew what to ask, though ;)

We're open to general "I'm trying to do this and having problems" questions on the mailing lists. You probably would've needed to know to CC me specifically, though; sadly, I can't keep up with all the lists I need to.

Good to know. Thanks! I will come back to you once I get rid of our O(100) clang patches to discuss what would be the best way of supporting incremental compilation.

That's quite brittle, because that code is only executed in a code path that only you are using, and you're not adding any tests. I would greatly prefer a change to IRGen's core assumptions, as suggested.

I am open to changing this code as well. That should probably be another review.

I agree. Are you comfortable with blocking this review until that lands? It seems like it would significantly change this.

In D34444#812418, @rjmccall wrote:

In D34444#795175, @v.g.vassilev wrote:

@rjmccall, thanks for the prompt and thorough reply.

In D34444#793311, @rjmccall wrote:

Okay. In that case, I see two problems, one major and one potentially major.

This is a very accurate diagnosis which took us 5 years to discover on an empirical basis ;)

You could've asked at any time. :)

I think we can rely on a post-commit review here. LGTM!

LGTM!

Remove accidentally added change in SemaDecl.cpp