From a purely personal perspective, I'd prefer if this landed after the branch for llvm-15.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 20 2022
Jul 17 2022
In D112374#3657640, @mizvekov wrote:In D112374#3657472, @kimgr wrote:I'm coming at this from pretty far away, so there's very likely lots of details that I'm overlooking. But it seems to me the mainline had only had an ElaboratedType node if there was elaboration, and not otherwise. And that makes a lot more sense to me than having 2 ElaboratedType* nodes _for every type in the AST_, just to express that "hey, by the way, this type had no elaboration".
There are no 2 ElaboratedType nodes, there is only one. If you are seeing something like an ElaboratedType wrapping directly over another ElaboratedType, that would seem to be a bug.
Jul 16 2022
It's the difference in knowing the type was written without any tag or nested-name specifier, and having a type that you are not sure how it was written.
When we are dealing with a type which we are not sure, we would like to print it fully qualified, with a synthetic nested name specifier computed from it's DC,
because otherwise it could be confusing as the type could come from somewhere very distant from the context we are printing the type from. We would not
want to assume that a type which has been desugared was written how it's desugared state would seem to imply.
It's a little confusing, because it now looks like _every_ Type in the AST is wrapped in an ElaboratedTypeLoc + ElaboratedType. IWYU's debug AST dump shows this (excerpt):
tests/cxx/sizeof_reference.cc:51:8: (1) [ VarDecl ] size_t s2 tests/cxx/sizeof_reference.cc:51:1: (2) [ ElaboratedTypeLoc ] size_t tests/cxx/sizeof_reference.cc:51:1: (2) [ ElaboratedType ] size_t tests/cxx/sizeof_reference.cc:51:1: (3) [ TypedefTypeLoc ] size_t tests/cxx/sizeof_reference.cc:51:1: (3) [ TypedefType ] size_t Marked full-info use of decl size_t (from /home/kimgr/code/iwyu/out/main/lib/clang/15.0.0/include/stddef.h:46:23) at tests/cxx/sizeof_reference.cc:51:1 tests/cxx/sizeof_reference.cc:51:13: (2) [ UnaryExprOrTypeTraitExpr ] UnaryExprOrTypeTraitExpr 0x5589fd2a4230 'unsigned long' sizeof 'IndirectTemplateStruct<IndirectClass> &'
Jul 13 2022
This patch also broke IWYU, not exactly sure how or why yet. We run around the AST quite a bit, so structural changes like this often bite us.
Mar 22 2022
Now that D119477 has landed, this suggested change is obsolete. Closing.
Mar 19 2022
Thanks! Could you help me land it? Author: Kim Gräsman <kim.grasman at gmail.com>.
Address review feedback
Mar 18 2022
Mar 14 2022
@aaron.ballman Friendly Monday ping.
@aaron.ballman Friendly Monday ping.
Mar 6 2022
Gentle weekly ping
Gentle weekly ping
Feb 27 2022
Fix typo in comment.
I have a local branch with both D119476 and this patch.
Feb 20 2022
Having looked at this some more, I wonder if this patch is covering for another problem. Running even the simplest example fails on an assertion in Sema::BuildCXXTypeConstructExpr: https://godbolt.org/z/fMPcsh4f3.
Feb 19 2022
I can also confirm that main and my branch (containing https://reviews.llvm.org/D119477 and https://reviews.llvm.org/D119476) both assert on the same line:
$ cat ../../bug-53244.cc struct A { consteval A() {} A(const A&) = delete; consteval void f() {} };
First sanity check: applying this patch on my branch causes no test failures either in the tools/clang/unittests/Tooling/ToolingTests or ninja check-clang-semacxx. Hopefully I can think this through more deeply soon.
Feb 15 2022
Thanks for the heads-up! I'm a little busy this week, but I need to think about potential interference between these two changes. Off the top of my head it looks like they should get along fine, but there may be subtleties.
Feb 10 2022
@aaron.ballman This patch replaces https://reviews.llvm.org/D117391 as a potential solution for https://github.com/llvm/llvm-project/issues/53044.
@aaron.ballman First refactor to generalize and harmonize getSubExprAsWritten and getConversionFunction. As mentioned in the commit message, this is strictly speaking a functional change, but it should have no visible effect.
Feb 7 2022
@aaron.ballman Thanks for the valuable feedback!
Feb 6 2022
I have now convinced myself that including FullExpr in skipImplicitTemporary gives an improvement in consteval diagnostics. But I'm still not sure why. Motivating example, derived from cxx2a-consteval.cpp:
struct A { int *p = new int(42); consteval A ret_a() const { return A{}; } };
Feb 3 2022
Feb 2 2022
Here's the diff between my patch (main) and handling FullExpr in skipImplicitTemporary as in the diff I posted above (patch.txt):
--- main.txt 2022-02-02 20:37:21.619534225 +0100 +++ patch.txt 2022-02-02 20:34:17.016949227 +0100 @@ -192,6 +192,13 @@ /home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:360:25: note: temporary created here { A k = to_lvalue_ref(A()); } // expected-error {{is not a constant expression}} ^ +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:362:25: error: call to consteval function 'alloc::A::ret_a' is not a constant expression + { A k = to_lvalue_ref(A().ret_a()); } // expected-error {{is not a constant expression}} + ^ +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:362:25: note: pointer to heap-allocated object is not a constant expression +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:334:12: note: heap allocation performed here + int* p = new int(42); + ^ /home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:362:11: error: call to consteval function 'alloc::to_lvalue_ref' is not a constant expression { A k = to_lvalue_ref(A().ret_a()); } // expected-error {{is not a constant expression}} ^ @@ -199,6 +206,27 @@ /home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:362:25: note: temporary created here { A k = to_lvalue_ref(A().ret_a()); } // expected-error {{is not a constant expression}} ^ +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:364:13: error: call to consteval function 'alloc::A::ret_a' is not a constant expression + { int k = A().ret_a().ret_i(); } + ^ +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:364:13: note: pointer to heap-allocated object is not a constant expression +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:334:12: note: heap allocation performed here + int* p = new int(42); + ^ +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:370:25: error: call to consteval function 'alloc::A::ret_a' is not a constant expression + { int k = const_a_ref(A().ret_a()); } + ^ +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:370:25: note: pointer to heap-allocated object is not a constant expression +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:334:12: note: heap allocation performed here + int* p = new int(42); + ^ +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:371:39: error: call to consteval function 'alloc::A::ret_a' is not a constant expression + { int k = const_a_ref(to_lvalue_ref(A().ret_a())); } + ^ +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:371:39: note: pointer to heap-allocated object is not a constant expression +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:334:12: note: heap allocation performed here + int* p = new int(42); + ^ /home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:375:14: error: call to consteval function 'alloc::A::ret_a' is not a constant expression { int k = (A().ret_a(), A().ret_i()); }// expected-error {{is not a constant expression}} ^ @@ -206,6 +234,13 @@ /home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:334:12: note: heap allocation performed here int* p = new int(42); ^ +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:377:26: error: call to consteval function 'alloc::A::ret_a' is not a constant expression + { int k = (const_a_ref(A().ret_a()), A().ret_i()); } + ^ +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:377:26: note: pointer to heap-allocated object is not a constant expression +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:334:12: note: heap allocation performed here + int* p = new int(42); + ^ /home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:400:7: error: call to consteval function 'self_referencing::f' is not a constant expression s = f(0); // expected-error {{is not a constant expression}} ^ @@ -454,9 +489,9 @@ /home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:548:15: note: declared here consteval int f_eval() { // expected-note+ {{declared here}} ^ -/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:574:25: error: cannot take address of consteval function 'f_eval' outside of an immediate invocation - { Copy c = Copy(Copy(&f_eval)); }// expected-error {{cannot take address of consteval}} - ^ +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:567:19: error: cannot take address of consteval function 'f_eval' outside of an immediate invocation + { Copy c((Copy(&f_eval))); }// expected-error {{cannot take address of consteval}} + ^ /home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:548:15: note: declared here consteval int f_eval() { // expected-note+ {{declared here}} ^ @@ -466,9 +501,9 @@ /home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:548:15: note: declared here consteval int f_eval() { // expected-note+ {{declared here}} ^ -/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:567:19: error: cannot take address of consteval function 'f_eval' outside of an immediate invocation - { Copy c((Copy(&f_eval))); }// expected-error {{cannot take address of consteval}} - ^ +/home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:574:25: error: cannot take address of consteval function 'f_eval' outside of an immediate invocation + { Copy c = Copy(Copy(&f_eval)); }// expected-error {{cannot take address of consteval}} + ^ /home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:548:15: note: declared here consteval int f_eval() { // expected-note+ {{declared here}} ^ @@ -501,4 +536,4 @@ a() + d(); // expected-error {{call to consteval function 'PR48235::A::a' is not a constant expression}} \ ^ /home/kimgr/code/llvm-project/clang/test/SemaCXX/cxx2a-consteval.cpp:661:5: note: implicit use of 'this' pointer is only allowed within the evaluation of a call to a 'constexpr' member function -84 errors generated. +89 errors generated.
Alright, with this diff:
diff --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp index d502b3f1e93e..1716ac0be7ef 100644 --- a/clang/lib/AST/Expr.cpp +++ b/clang/lib/AST/Expr.cpp @@ -1908,6 +1908,9 @@ namespace { if (auto *Binder = dyn_cast<CXXBindTemporaryExpr>(E)) E = Binder->getSubExpr();
@aaron.ballman @davrec Thank you both!
@aaron.ballman Thanks! Please use Kim Gräsman and kim.grasman at gmail.com.
Jan 31 2022
@rsmith Gentle ping
@rsmith Gentle ping
We've had reports from users that it's now possible to build IWYU together with Clang and LLVM using LLVM_EXTERNAL_PROJECTS, so this can be closed.
Jan 24 2022
@rsmith Weekly ping
@rsmith Weekly ping
Jan 16 2022
- Update broken test case
- Rebase on latest main (8eb74626f)
- Build and run ninja check-clang
Fix spurious semicolon
@daverec I don't have commit access, could you help me land this?
Jan 15 2022
Oh yeah, this closes bug https://github.com/llvm/llvm-project/issues/53044. Do I mention that in the commit message/patch summary?
Aug 3 2021
@dblaikie I think @sammccall mentioned IWYU pragma: friend before, that's what I was alluding to. Much of IWYU's complexity comes from maintaining these library mappings both statically (using mapping tables) and dynamically (using in-source annotations).
Hi, sorry I'm late to the game. IWYU maintainer here.
Jun 7 2021
This was eventually fixed in IWYU based on @jkorous' suggestion above. I believe the problem is/was:
This was eventually fixed in IWYU. I believe the problem is/was:
Jan 23 2020
In D72703#1834177, @hans wrote:I assume the same correlation could also be found with lines of code, but I think tokens is a better dimension to measure since it's less likely to be gamed, and it also is also kind of the basic work unit that the compiler deals with.
Jan 22 2020
A small Python suggestion.
Jan 21 2020
I just want to say that finding the correlation between token count and compile time is a bit of a breakthrough! Could you expose a flag for printing token count so users can run their own analysis? Or does that already exist in baseline clang? It's easier to set a maximum for a codebase if the distribution is known.
Nov 17 2019
Oh, I see. I thought rc.exe was the one and only implementation. Fair enough, this is probably the lesser of two evils :)
Nov 16 2019
I wonder if it would be better to look at the compile-command than the source file?
Sep 28 2019
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
In D62115#1547705, @skan wrote:In D62115#1547698, @kimgr wrote:This looks good to me, thanks!
Could you help accept this patch?
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
Hi Alex,
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.