llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `premerge-monolithic-linux`
running on `premerge-linux-1` while building `clang-tools-extra` at step 7
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/153/builds/158
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-x86_64-debian-fast`
running on `gribozavr4` while building `clang-tools-extra` at step 6
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/56/builds/13090
Her
HighCommander4 wrote:
Resubmitted with the build failures fixed at
https://github.com/llvm/llvm-project/pull/117673.
https://github.com/llvm/llvm-project/pull/77556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`sanitizer-x86_64-linux-bootstrap-msan` running on `sanitizer-buildbot6` while
building `clang-tools-extra` at step 2 "annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/164/builds/4934
Here i
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-aarch64-quick`
running on `linaro-clang-aarch64-quick` while building `clang-tools-extra` at
step 5 "ninja check 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/65/builds/8369
Here is the r
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-armv8-quick` running
on `linaro-clang-armv8-quick` while building `clang-tools-extra` at step 5
"ninja check 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/154/builds/8052
Here is the rele
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-m68k-linux-cross`
running on `suse-gary-m68k-cross` while building `clang-tools-extra` at step 5
"ninja check 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/27/builds/2558
Here is the rele
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clangd-ubuntu-tsan`
running on `clangd-ubuntu-clang` while building `clang-tools-extra` at step 5
"build-clangd-clangd-index-server-clangd-indexer".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/134/
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `llvm-clang-aarch64-darwin`
running on `doug-worker-5` while building `clang-tools-extra` at step 5
"build-unified-tree".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/190/builds/10189
Here is the r
https://github.com/HighCommander4 closed
https://github.com/llvm/llvm-project/pull/77556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
HighCommander4 wrote:
> Appears to work fine. Regarding the slight memory increase: If anyone feels
> strongly about it, they had plenty of time to chime in.
Thanks! I'll go ahead and merge.
https://github.com/llvm/llvm-project/pull/77556
___
cfe-com
@@ -1700,6 +1700,7 @@ declToHierarchyItem(const NamedDecl &ND, llvm::StringRef
TUPath) {
HierarchyItem HI;
HI.name = printName(Ctx, ND);
+ // FIXME: Populate HI.detail the way we do in symbolToHierarchyItem?
HighCommander4 wrote:
See also https://github
pidgeon777 wrote:
First of all, I want to express my gratitude to all contributors working on the
integration of changes and tests.
In today's development landscape, especially when working with AI-assisted
coding, providing the best possible code context is crucial. The integration of
outgoi
https://github.com/ckandeler approved this pull request.
Appears to work fine.
Regarding the slight memory increase: If anyone feels strongly about it, they
had plenty of time to chime in.
https://github.com/llvm/llvm-project/pull/77556
___
cfe-commit
https://github.com/i-garrison edited
https://github.com/llvm/llvm-project/pull/77556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1700,6 +1700,7 @@ declToHierarchyItem(const NamedDecl &ND, llvm::StringRef
TUPath) {
HierarchyItem HI;
HI.name = printName(Ctx, ND);
+ // FIXME: Populate HI.detail the way we do in symbolToHierarchyItem?
i-garrison wrote:
I see. Ideally there should
HighCommander4 wrote:
Thanks @ckandeler for the review! I addressed the comments in
https://github.com/llvm/llvm-project/pull/77556/commits/bad4f7264433417763ea35bc1104fb087c8725e5.
https://github.com/llvm/llvm-project/pull/77556
___
cfe-commits maili
@@ -2346,11 +2346,11 @@ outgoingCalls(const CallHierarchyItem &Item, const
SymbolIndex *Index) {
// Filter references to only keep function calls
using SK = index::SymbolKind;
auto Kind = Callee.SymInfo.Kind;
-if (Kind != SK::Function && Kind != SK::InstanceMet
@@ -1700,6 +1700,7 @@ declToHierarchyItem(const NamedDecl &ND, llvm::StringRef
TUPath) {
HierarchyItem HI;
HI.name = printName(Ctx, ND);
+ // FIXME: Populate HI.detail the way we do in symbolToHierarchyItem?
HighCommander4 wrote:
The difference between
@@ -1751,6 +1752,7 @@ static std::optional
symbolToHierarchyItem(const Symbol &S,
}
HierarchyItem HI;
HI.name = std::string(S.Name);
+ HI.detail = (S.Scope + S.Name).str();
HighCommander4 wrote:
I agree, showing the signature here would be quite useful
@@ -88,56 +89,6 @@
# CHECK-NEXT: }
# CHECK-NEXT: ]
---
-{"jsonrpc":"2.0","id":2,"method":"typeHierarchy/subtypes","params":{"item":{"uri":"test:///main.cpp","data":{"parents":[{"parents":[{"parents":[],"symbolID":"FE546E7B648D69A7"}],"symbolID":"ECDC0C46D75120F4"}],"symbol
@@ -2346,11 +2346,11 @@ outgoingCalls(const CallHierarchyItem &Item, const
SymbolIndex *Index) {
// Filter references to only keep function calls
HighCommander4 wrote:
Reworded
https://github.com/llvm/llvm-project/pull/77556
___
https://github.com/HighCommander4 updated
https://github.com/llvm/llvm-project/pull/77556
>From f3d2263730129760da56254d145bd69d66463775 Mon Sep 17 00:00:00 2001
From: Quentin Chateau
Date: Mon, 18 Sep 2023 03:01:03 -0400
Subject: [PATCH 1/5] [clangd] Support outgoing calls in call hierarchy
T
HighCommander4 wrote:
Rebased.
https://github.com/llvm/llvm-project/pull/77556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/HighCommander4 updated
https://github.com/llvm/llvm-project/pull/77556
>From f3d2263730129760da56254d145bd69d66463775 Mon Sep 17 00:00:00 2001
From: Quentin Chateau
Date: Mon, 18 Sep 2023 03:01:03 -0400
Subject: [PATCH 1/4] [clangd] Support outgoing calls in call hierarchy
T
HighCommander4 wrote:
@ckandeler, perhaps you would be willing to review this patch? I don't seem to
have gotten any traction from my usual reviewers over the course of the past
year.
https://github.com/llvm/llvm-project/pull/77556
___
cfe-commits ma
@@ -1700,6 +1700,7 @@ declToHierarchyItem(const NamedDecl &ND, llvm::StringRef
TUPath) {
HierarchyItem HI;
HI.name = printName(Ctx, ND);
+ // FIXME: Populate HI.detail the way we do in symbolToHierarchyItem?
i-garrison wrote:
is this the place which cov
@@ -1751,6 +1752,7 @@ static std::optional
symbolToHierarchyItem(const Symbol &S,
}
HierarchyItem HI;
HI.name = std::string(S.Name);
+ HI.detail = (S.Scope + S.Name).str();
i-garrison wrote:
adding signature looks a bit more helpful, maybe one day add
@@ -88,56 +89,6 @@
# CHECK-NEXT: }
# CHECK-NEXT: ]
---
-{"jsonrpc":"2.0","id":2,"method":"typeHierarchy/subtypes","params":{"item":{"uri":"test:///main.cpp","data":{"parents":[{"parents":[{"parents":[],"symbolID":"FE546E7B648D69A7"}],"symbolID":"ECDC0C46D75120F4"}],"symbol
@@ -2346,11 +2346,11 @@ outgoingCalls(const CallHierarchyItem &Item, const
SymbolIndex *Index) {
// Filter references to only keep function calls
using SK = index::SymbolKind;
auto Kind = Callee.SymInfo.Kind;
-if (Kind != SK::Function && Kind != SK::InstanceMet
@@ -2346,11 +2346,11 @@ outgoingCalls(const CallHierarchyItem &Item, const
SymbolIndex *Index) {
// Filter references to only keep function calls
ckandeler wrote:
This comment doesn't really apply anymore.
https://github.com/llvm/llvm-project/pull/77556
__
pidgeon777 wrote:
Hopefully we're closer and closer to a merge, this really is a missing feature.
I think this is the only LSP provider supporting just only one of the
callHierarchy methods.
https://github.com/llvm/llvm-project/pull/77556
___
cfe-com
HighCommander4 wrote:
@kadircet perhaps you might be able to pick up this review?
Or, barring of a full review, your opinion on the directional question in [this
comment](https://reviews.llvm.org/D93829#4654786) would be appreciated as well:
> how would you feel about proceeding with the patch
HighCommander4 wrote:
> I think other than the review it would be 100% done? I mean, no big further
> modifications would be involved?
In terms of functionality, I'd say the patch is complete.
In terms of performance (and specifically memory usage), it's a matter of
judgment of what we consid
pidgeon777 wrote:
I was thinking that it's a real pity this branch is so hard to get merged 😅 I
think other than the review it would be 100% done? I mean, no big further
modifications would be involved?
https://github.com/llvm/llvm-project/pull/77556
___
HighCommander4 wrote:
Shopping around for some potential alternative reviewers :)
https://github.com/llvm/llvm-project/pull/77556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pidgeon777 wrote:
@sam-mccall also pinging to assist @HighCommander4 🙂
https://github.com/llvm/llvm-project/pull/77556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
HighCommander4 wrote:
@sam-mccall review ping :)
https://github.com/llvm/llvm-project/pull/77556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
HighCommander4 wrote:
@sam-mccall review ping :)
I would particularly appreciate feedback on whether I should plan to set aside
some time to implement the "deep lookup optimization" (from [this
comment](https://reviews.llvm.org/D93829#4258101)), or whether the 2.5%
increase in index memory us
HighCommander4 wrote:
Since Phabricator has been [taken
down](https://discourse.llvm.org/t/llvm-phabricator-turndown/76137), I'm
resubmitting the patch implementing outgoing calls in call hierarchy that was
previously posted at https://reviews.llvm.org/D93829.
Previous discussion can still be
https://github.com/HighCommander4 edited
https://github.com/llvm/llvm-project/pull/77556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
41 matches
Mail list logo