I'm interested in this, I've tried for a while to fix the Debian packaging but I'm completely new to the packaging toolchain, so I'm making slow headway.

When using a PCH, tokens are skipped until after the through header is seen.

In D43578#1067974, @rsmith wrote:

In D43578#1067891, @kimgr wrote:

I disagreed up until the last paragraph :)

Can you say which things you disagree with? There seem to be two important facts here:

1. LLVM's timing infrastructure cannot correctly report timings when one function containing a timing region calls another. That will happen all the time with this patch applied.
2. Clang's architecture means that if you time the amount of time spent in, say, the "ParseTemplate" function, you have not computed the amount of time spent parsing templates, because the parser calls into Sema, which might perform tasks that are only somewhat related to parsing the template (such as performing other instantiations), and likewise Sema calls into other layers (such as AST file deserialization and code generation).

The first might have been fixed in LLVM at this point, but I can't see any evidence of that in LLVM's Timer implementation. And the second seems even more fundamental. But if there's some way around that, which would allow us to produce (correct!) numbers for times spent parsing / whatever else, without, for instance, adding a correctness requirement that we annotate every Parser -> Sema entry point with a timer, then that's definitely something we should discuss.

Heh, my e-mail response was eaten along the way. Continued here:

Hi Richard,

I have to say I disagree that either the nested struct/function or macros
(in any form) should count toward a function's total variable count.

Peanut gallery observation: there was a discussion on the Boost list years and years ago where someone made the case that if (x != nullptr) delete x; was measurably faster than just calling delete x; I can't find it now, but I think it might have been in the context of their checked_delete library. Anyway, the reasoning was that with an external nullptr check, you'd pay for one comparison, but without it you'd always pay for a jump + a comparison. I suppose that only holds true for null pointers, for non-null pointers the extra check is just waste.

Ping! It would be nice to get some traction on this.

Typo in the commit title: buzzer :)

Why? It seems easier to me to map back if the diagnostic mirrors the code as-written.

I was about to suggest SymbolLocation or even SymbolLoc, but it appears to keep track of more than locations. "Reference" sounds a little open-ended. No more ideas here, I'm afraid.

High-level comment from the peanut gallery:

Any chance you could try my example too? It seems like this approach might catch it.

I've seen this in the wild:

only for the function templates that use Microsoft intrinsics (e.g. _BitScanForward in TrailingZerosCounter<T>.)
So there's something in the parsing of builtins/intrinsics that requires TUScope to be non-null.

I did some more debugging today. This happens when we attempt to analyze llvm/Support/MathExtras.h, and only for the function templates that use Microsoft intrinsics (e.g. _BitScanForward in TrailingZerosCounter<T>.) So there's something in the parsing of builtins/intrinsics that requires TUScope to be non-null.

We'd love to see this addressed, either in our code or in Clang. But we're not sure what to do on our end, so... a gentle ping for help!

We have a large closed-source codebase with this style, and would welcome clang-format support.

Python 3 concern inline

For some context, the backtrace when this happens is:

BTW, kimgr@, is there any particular reason you haven't tried to upstream the tool?
Maybe even as not a standalone tool but as a set of checks in clang-tidy.

As an include-what-you-use maintainer, I would very much welcome this. I've been too shy to suggest it myself ;-).

A few more 'inhertiance' left, otherwise spelling looks good to me :-)

Oops, the flag is called BreakBeforeInhertianceComma with a misspelling throughout. May want to search for inhertiance throughout and see if there are more cases.

Some nits from a Python3 hacker.

For what it's worth, I also find this useful to be able to see at a glance what the setting does. I know I've tried several different settings in the past before finding the one I was looking for.

... and both revisions should be in the 4.0 branch (taken from r291814)

I think we're seeing similar new behavior in IWYU, I've been meaning to bring it up on cfe-dev. But since it might be relevant here, I'll add our observations.

I agree. Since the current set of encodings all have different element sizes and this is not likely to change, this looks good.

Another belated thought: it all depends on the intended meaning of the symbol:

@smeenai I think I tried to make a jumbled mess of points :-)

Re Eric's windows.h concern.

I don't think wchar_t is UCS-2 anymore, I read somewhere that they switched to UTF-16 as of Windows 2000.

Minor spelling nits inline

This is probably not the right place for this discussion, but I thought I'd offer one more note.

Inline question on ctor+nullptr

I only caught this typo after it was committed.

Re semantics, you may want to link to IWYU's docs at
https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUPragmas.md
.

The RUN line looks weird to me, but I'm no lit expert...

A test case would be nice here. You can repro on all systems by passing -fdelayed-template-parsing explicitly.

Cool check, I like how it pays attention to indentation!

Came up with another test case.

Comment at: tools/scan-build-py/bin/analyze-cc:14
@@ +13,2 @@
+from libscanbuild.analyze import wrapper

+sys.exit(wrapper(False))

It is hard to figure out/search which functions actually get called from the top level tools. Could you rename all of the public functions so that they
have unique names? For example, "wrapper" -> "scan_build_wrapper". This would greatly improve searchability!

Add debugging ideas.

Thanks! I just looked at this again, and I think I found a bug, see inline.

Some style nits and a question around the purpose of Sr. It doesn't appear to do what I thought it would.

Added some ideas for tests that might break.

Also, is a test possible? I still haven't got my head around the Clang test fx, but it feels like it should be possible to create a .gch in a temporary path, add the path to -I and verify that clang sees it when you attempt to force it in with -include.

My co-worker (who reported the bug) has tested the patch and it works in our build system, so the patch is functional.

See inline.

... and by 'should', I mean what I intended, to avoid this fallback when the chance of dependent bases is zero.

Thanks! Could you try this one instead? I think it's more representative of what we should do, i.e. only fall back if we're in a CXXRecordDecl and said record has dependent bases.

I've played with another approach, to just ask the DeclContext if its parent is a record, i.e.