- User Since
- Jul 30 2012, 5:35 AM (372 w, 6 d)
Jul 19 2019
On the fuzzer side, there's also -fsanitize=fuzzer-no-link (see http://llvm.org/docs/LibFuzzer.html#fuzzer-usage). Maybe it would be nice to harmonize all these?
Jun 30 2019
@sylvestre.ledru @beanz After this change, the Debian packaging on apt.llvm.org is basically broken. See https://bugs.llvm.org/show_bug.cgi?id=42432. I'm sure this can be fixed in packaging, but I don't know enough about it to know exactly what to do. At any rate I think the idea that libclang_shared.so.* can stay out of the published package is wrong. At least unless there's also a way to build the Clang tree withouth the clang_shared target.
Jun 18 2019
Jun 17 2019
This looks good to me, thanks!
Jun 11 2019
I think the test needs a bit more work. It's essentially checking the same thing twice to exercise the Windows path separators.
May 21 2019
I was thinking about a testcase like:
Also, consider ././Inputs/empty.h.
May 20 2019
Should you also consider Windows path separators here?
Mar 5 2019
Nov 16 2018
Here's some related suggestions/questions for context:
Oct 28 2018
Sep 3 2018
This appears ready to go, here's a weekly commit ping.
Aug 31 2018
@thakis I updated the Title/Summary to what I think is a reasonable commit message. Could you commit this for me? Thanks!
Aug 22 2018
Thanks! Could you also commit this for me?
Aug 20 2018
Aug 15 2018
I do not, could you commit it for me? Thanks!
Aug 13 2018
The title is probably no longer relevant, but I'm having trouble coming up with something apt. If this looks good, could you commit it for me with a reasonable message? Thanks!
Use llvm_unreachable to convince GCC that all is well.
The original code should have worked (Opc was constrained to storerb, storerh or storeri by validation earlier in the method), but GCC complained:
Aug 12 2018
If you're happy with this, could you also commit it for me? Thanks!
- Clarify comment
- Fix naming
- Update differential title/summary
Better solution in D50608.
Could you also commit this for me, I don't have commit privs. Thanks!
Thanks, me too!
Aug 1 2018
Potential typo in the tests
Jul 19 2018
Thank you for doing this, I'm going to guess you have IWYU in mind :-)
This can be closed, IWYU no longer officially supports in-tree builds.
May 17 2018
> Can you test what happens when you do clang-cl.exe /Yc stdafx.h /Tp stdafx.h, i.e. compile the header
> directly as C++ code and generate .pch from it? The normal MSVC modus operandi is to have stdafx.h
> included in all source files (with /Yu) and stdafx.cpp to generate it (with /Yc). That stdafx.cpp file serves
> no purpose, so I've played this trick to generate PCH from the header directly. If it works, it might also
> be useful for your tests.
It isn't always the case that the .cpp file serves no purpose. It's true that the MS project generators give you this setup but we've seen many projects over the years that use a regular source file with code in it to generate the PCH. The > object file generated during PCH create can have real code and the compiler can take advantage of that fact by compiling less code in the compilation units that use the PCH [...]
May 16 2018
I've done some terrible things with MSVC PCHs over the years, so I'll pile on some more questions:
May 12 2018
It works! Having to specify CMAKE_PREFIX_PATH is at least documentable, so I don't see that as a major drawback, especially if it makes docs for tools using Clang more portable.
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.
May 11 2018
When using a PCH, tokens are skipped until after the through header is seen.
Apr 14 2018
Heh, my e-mail response was eaten along the way. Continued here:
Mar 23 2018
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.
Feb 17 2018
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.
Jan 7 2018
Typo in the commit title: buzzer :)
Oct 26 2017
Why? It seems easier to me to map back if the diagnostic mirrors the code as-written.
Aug 2 2017
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.
Aug 1 2017
High-level comment from the peanut gallery:
Jul 24 2017
Any chance you could try my example too? It seems like this approach might catch it.
Jul 23 2017
I've seen this in the wild:
Jul 2 2017
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.
Jun 29 2017
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.
Jun 11 2017
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!
May 16 2017
We have a large closed-source codebase with this style, and would welcome clang-format support.
May 1 2017
Apr 20 2017
Python 3 concern inline
Apr 8 2017
For some context, the backtrace when this happens is:
Apr 6 2017
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.
Apr 5 2017
As an include-what-you-use maintainer, I would very much welcome this. I've been too shy to suggest it myself ;-).
Mar 10 2017
A few more 'inhertiance' left, otherwise spelling looks good to me :-)
Mar 9 2017
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.
Mar 3 2017
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.
Feb 1 2017
... and both revisions should be in the 4.0 branch (taken from r291814)
Jan 6 2017
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.
Jan 3 2017
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.
Dec 27 2016
Minor spelling nits inline
Jul 28 2016
This is probably not the right place for this discussion, but I thought I'd offer one more note.
Jul 21 2016
Inline question on ctor+nullptr
Jul 7 2016
I only caught this typo after it was committed.
May 4 2016
Re semantics, you may want to link to IWYU's docs at
Apr 7 2016
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.
Jan 25 2016
Cool check, I like how it pays attention to indentation!
Jan 19 2016
Came up with another test case.
Dec 13 2015
Comment at: tools/scan-build-py/bin/analyze-cc:14
@@ +13,2 @@
+from libscanbuild.analyze import wrapper
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!
Nov 7 2015
Add debugging ideas.