This is an archive of the discontinued LLVM Phabricator instance.

[clangd] NFC: Update FIXME comment regarding lack of c/dtor support
ClosedPublic

Authored by kbobyrev on Oct 22 2020, 12:12 AM.

Details

Summary

Both SymbolKind and indexSymbolKindToSymbolKind support constructors and
separate them into a different category from regular methods.

Diff Detail

Event Timeline

kbobyrev created this revision.Oct 22 2020, 12:12 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 22 2020, 12:12 AM
kbobyrev requested review of this revision.Oct 22 2020, 12:12 AM
njames93 added inline comments.
clang-tools-extra/clangd/FindSymbols.cpp
182–183
kbobyrev updated this revision to Diff 299891.Oct 22 2020, 1:29 AM
kbobyrev marked an inline comment as done.

Fix typo.

clang-tools-extra/clangd/FindSymbols.cpp
182–183

Oops, thanks!

Am I missing something? We still have:

case index::SymbolKind::Constructor:
case index::SymbolKind::Destructor:
  return SymbolKind::Constructor;

in Protocol.cpp. E.g. Constructors and Destructors are still classified badly. I suppose the bit around they're all methods are wrong though, maybe just drop that bit ?

Am I missing something? We still have:

case index::SymbolKind::Constructor:
case index::SymbolKind::Destructor:
  return SymbolKind::Constructor;

in Protocol.cpp. E.g. Constructors and Destructors are still classified badly. I suppose the bit around they're all methods are wrong though, maybe just drop that bit ?

Yeah but the LSP SymbolKind which we are converting to does not have a destructor type, same thing with CompletionItemKind, so I guess we really do treat ctors and dtors the same way from the LSP perspective, aren't we?

Yeah but the LSP SymbolKind which we are converting to does not have a destructor type, same thing with CompletionItemKind, so I guess we really do treat ctors and dtors the same way from the LSP perspective, aren't we?

Yes, and that's what the previous fixme was saying. Now we are dropping that bit, but the code is still behaving badly?

I thought the point of the comment was us not handling it properly rather than LSP not supporting it (e.g. LSP does support Operator but we do not). Then, the comment about ctor and dtor being indistinguishable probably belongs to Protocol.h/cpp and SymbolKind there in particular?

I thought the point of the comment was us not handling it properly rather than LSP not supporting it (e.g. LSP does support Operator but we do not). Then, the comment about ctor and dtor being indistinguishable probably belongs to Protocol.h/cpp and SymbolKind there in particular?

If that was the case I would expect this comment to be above previous line, i.e. index::getSymbolInfo, as that's the one doing the clang-level mapping. Whereas indexSymbolKindToSymbolKind does LSP mapping.

nridge added a subscriber: nridge.Oct 24 2020, 4:07 PM

Note, I've cargo-culted this comment into declToTypeHierarchyItem() as well, so whatever change we make here should be made there too.

kbobyrev updated this revision to Diff 300660.Oct 26 2020, 7:07 AM

Only drop the bits about "they're all considered methods", update XRefs.cpp.

kbobyrev updated this revision to Diff 300661.Oct 26 2020, 7:07 AM

Rebase on top of master.

kadircet accepted this revision.Oct 26 2020, 7:14 AM
This revision is now accepted and ready to land.Oct 26 2020, 7:14 AM
This revision was landed with ongoing or failed builds.Oct 26 2020, 7:32 AM
This revision was automatically updated to reflect the committed changes.
Harbormaster completed remote builds in B76392: Diff 300661.