Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 32824 Build 32823: arc lint + arc unit
Event Timeline
Do we care about pointers or references to lambda types?
clang-tools-extra/clangd/XRefs.cpp | ||
---|---|---|
662 | Variable types can be null (for C++17 deconstruction syntax), use getTypePtrOrNull. | |
664 | NIT: add extra braces to the inner if for more readable code | |
669 | NIT: add extra braces to the inner if for more readable code |
Nice catch! I think it makes sense to show signature in those cases as well.
Updating according to that.
Those cases are pretty rare, though, so I wasn't even sure they were worth it. They are pretty cheap to handle, though, so LG.
LGTM with a few last second NITs
clang-tools-extra/clangd/XRefs.cpp | ||
---|---|---|
664 | Uh, I meant the outer if, sorry for the confusion. My idea is that only one level of nesting is allowed to omit braces. if (condition1) { if (condition2) return true; } Not a big deal, though, don't want to nit-pick on minor code style issues. Feel free to tailor to your liking | |
clang-tools-extra/clangd/unittests/XRefsTests.cpp | ||
810 | Could you add another test with even weirder types where we fail to show the signature? To make sure we don't break when reaching the limitations of the chosen approach and document what those limitations are. Something like: auto a = [](int a) { return 10; }; auto *b = &a; auto *c = &b; We would fail to show the signature here, but it's totally ok to ignore it. |
clang-tools-extra/clangd/XRefs.cpp | ||
---|---|---|
657 | can this be a separate function rather than a local lambda? I think the name could be clearer, e.g. getUnderlyingFunction | |
clang-tools-extra/clangd/unittests/XRefsTests.cpp | ||
798 | I'm slightly nervous about the fact that "lambda" doesn't appear anywhere here. e.g. maybe the Type should be "<lambda> bool(int, bool)" or so? |
clang-tools-extra/clangd/unittests/XRefsTests.cpp | ||
---|---|---|
798 | I've added the textual info to type. I don't think it is useful enough to put it as semantic info into the struct. I believe it is rather a visual cue to the user, which seems pretty available in the "Type" field. | |
810 | added cases, and changed code(a lot simpler now) to generate signatures for those cases as well. |
clang-tools-extra/clangd/XRefs.cpp | ||
---|---|---|
628 | We need a check for !QT.isNull here | |
clang-tools-extra/clangd/unittests/XRefsTests.cpp | ||
810 | Here's an example when the new approach falls short too: auto a = [](int) { return 10; } std::function<void(decltype(a) x)> b; In general, are we ok with loosing all the information about the type that we drop? At the same time, either case is so rare that we probably don't care. |
Please add a check for the type of variable being not null before landing. The other comment is not very important
clang-tools-extra/clangd/unittests/XRefsTests.cpp | ||
---|---|---|
810 | are you talking about hovering over x ? I don't think AST contains information regarding that one. for a code like this: auto foo = []() { return 5; }; template <class T> class Cls {}; Cls<void(decltype(foo) bar)> X; This is the AST dump for variable X: `-VarDecl 0x2b0e808 <line:6:1, col:30> col:30 X 'Cls<void (decltype(foo))>':'Cls<void ((lambda at a.cc:1:12))>' callinit `-CXXConstructExpr 0x2b12e80 <col:30> 'Cls<void (decltype(foo))>':'Cls<void ((lambda at a.cc:1:12))>' 'void () noexcept' |
clang-tools-extra/clangd/unittests/XRefsTests.cpp | ||
---|---|---|
810 | I'm talking about hovering over b and, as Sam mentioned, there's a good chance you don't have this information in the type and we need to look at TypeLocs instead. Also agree with Sam, we don't want any complexity for that case. Just wanted to make sure we added a test like this just to make sure we have some idea of what's produced there and it does not crash. |
- Address comments
clang-tools-extra/clangd/unittests/XRefsTests.cpp | ||
---|---|---|
810 | I see, but then I don't think this case has anything to do with current patch, right? It becomes a matter of decomposing a type with sugared components(which I believe should be visited but not in this patch) rather than expanding a lambda to a function like. |
clang-tools-extra/clangd/unittests/XRefsTests.cpp | ||
---|---|---|
810 | Sorry, I missed that we still have the Type field set which will contain all pointers/references. |
We need a check for !QT.isNull here