Try to show parents in the initial type hierarchy tree as well

[HighCommander4]

No description provided.

[HighCommander4]

This required a server-side change as well: https://reviews.llvm.org/D81845

[HighCommander4]

(This should be ready to review along with the dependent PR #20.)

[HighCommander4]

(Rebased on top of the landing of #20.)

[hokein]

I played it around locally -- it works great for simple examples! but for a real LLVM project, I encountered some issues (some of them might be related to clangd), below are the details

• open clang/lib/ARCMigrate/TransUnbridgedCasts.cpp, invoke type hierarchy on UnbridgedCastRewriter (Line 59), the debug console throws an exception [1];
• results on RecursiveASTVisitor[2] seem odd, and incomplete;
• no result on clang::clangd::ParsingCallbacks, it maybe caused by the fact that we don't collect main-file symbols;

rejected promise not handled within 1 second: Error: Cannot resolve tree item for element 0/0:RecursiveASTVisitor<(anonymous namespace)::UnbridgedCastRewriter>/0:UnbridgedCastRewriter
extensionHostProcess.js:976
stack trace: Error: Cannot resolve tree item for element 0/0:RecursiveASTVisitor<(anonymous namespace)::UnbridgedCastRewriter>/0:UnbridgedCastRewriter
	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:609:64

[2]:

[HighCommander4]

I played it around locally -- it works great for simple examples! but for a real LLVM project, I encountered some issues (some of them might be related to clangd), below are the details

Thanks very much for testing!

• open clang/lib/ARCMigrate/TransUnbridgedCasts.cpp, invoke type hierarchy on UnbridgedCastRewriter (Line 59), the debug console throws an exception [1];

I'm able to reproduce this, somewhat intermittently. I don't really understand the cause; as far as I can tell, I'm using the VSCode API as documented (e.g. implementing TreeDataProvider.getParent() so I can use TreeView.reveal()). Also, I don't see any actual problem caused by it (i.e. the tree shows up just like in the cases where I don't get the error).

I added a commit to the PR which provides a rejection handler to catch this error and print a warning instead of letting VSCode throw an exception; I don't have a better idea for what to do.

• results on RecursiveASTVisitor[2] seem odd, and incomplete;

There turned out to be three different server-side issues here: clangd/clangd#504, clangd/clangd#507, and clangd/clangd#510. The first two are fixed and I have a patch up for the third.

• no result on clang::clangd::ParsingCallbacks, it maybe caused by the fact that we don't collect main-file symbols;

This is also fixed by clangd/clangd#510.

[hokein]

@HighCommander4 could you rebase it to master?

[HighCommander4]

Rebased.

[HighCommander4]

Rebased again.

[HighCommander4]

@hokein do you think this is ready to be merged now? The issues described in this comment are now all resolved, and the patch has been rebased.

[hokein]

looks good.

[hokein]

this is very unfortunate, but it seems there are no visible effects, we can live with that.

btw, I see some logs (not sure they are helpful)

Warning: TreeView.reveal() failed for reason: Error: Cannot resolve tree item for element 0/0:RecursiveASTVisitor<(anonymous namespace)::UnbridgedCastRewriter>/0:UnbridgedCastRewriter
type-hierarchy.js:250
Warning: TreeView.reveal() failed for reason: Error: TreeError [clangd.typeHierarchyView] Data tree node not found: [object Object]

[HighCommander4]

Thanks!

btw, I see some logs (not sure they are helpful)

I see the same thing. Unfortunately, I have not been able to figure out what sort of misuse of the TreeView API (if any) this translates to. If anyone has ideas about this, I'm happy to come back to this and try them out.