This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Add access specifier information to hover contents
ClosedPublic

Authored by danielmartin on May 23 2020, 7:58 AM.

Details

Summary

For https://github.com/clangd/clangd/issues/382

This commit adds access specifier information to the hover
contents. For example, the hover information of a class field or
member function will now indicate if the field or member is private,
public, or protected. This can be particularly useful when a developer
is in the implementation file and wants to know if a particular member
definition is public or private.

Diff Detail

Event Timeline

danielmartin created this revision.May 23 2020, 7:58 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 23 2020, 7:58 AM
danielmartin edited the summary of this revision. (Show Details)May 23 2020, 8:01 AM

thanks for taking a look at this, this looks great!

mostly nits, but the one in tests is important and annoying (it might require you to update some existing cases)

clang-tools-extra/clangd/Hover.cpp
680

it is annoying to have this function duplicated in each component (there are duplicates at least in text and json node dumpers too) :/

Feel free to provide a common implementation in clang/include/clang/Basic/Specifiers.h and migrate all other usages to it, or just put a FIXME in here saying we should converge those.

nit: prefer llvm::StringRef as return type

779

I wonder if it would be more natural to put this at bottom, where we list the containing class/struct/union. e.g.

struct X { int fo^o; }

would result in

field foo
---

// In X
public: int foo

I find current one useful too, just listing options to see what you (and possibly others interested in) think.

clang-tools-extra/clangd/Hover.h
63

Let's have std::string here, with a comment saying that Access specifier for declarations inside class/struct/unions, empty for others.

clang-tools-extra/clangd/unittests/HoverTests.cpp
730–731

could you also add an EXPECT_EQ for H->AccessSpecifier ?

Move clang::getAccess to Specifiers.h and refactor logic in clang-doc
to use that function instead of its own.

Also changes where "public", "private" etc. is shown in the hover
contents. Now it's shown at the bottom.

Strengthens an existing unit test to also check for access specifiers.

danielmartin marked 6 inline comments as done.May 24 2020, 2:07 PM
danielmartin added inline comments.
clang-tools-extra/clangd/Hover.cpp
680

I've only found usages in clang-doc, I don't know if there's more.

I've changed them to use the new common logic in Specifiers.h.

779

I think it's a bit less visible, but one good thing your suggestion has is that in the Emacs client we use that part of the hover content to show a one liner with type information. So I followed your suggestion to also have access specifier information in our one-liner.

kadircet accepted this revision.May 25 2020, 1:35 AM
kadircet marked an inline comment as done.

thanks! LGTM with some minor comments.

let me know if you don't have commit access so that i can land this for you.

clang-tools-extra/clangd/Hover.cpp
470–472

nit: you can do getAccess(D->getAccess()).str() (same for other places as well)

680
clang-tools-extra/clangd/unittests/HoverTests.cpp
616

this is surprising, but looks like sema always instantiates template parameters with public access specifiers explicitly.

no action needed, just leaving out comments in case we want to act on it in the future.

clang/include/clang/Basic/Specifiers.h
369

getAccessSpelling instead of getAccess

This revision is now accepted and ready to land.May 25 2020, 1:35 AM
danielmartin marked 2 inline comments as done.

Address feedback

Rename getAccess to getAccessSpelling.
Replace more parts of the codebase that were using their own version of getAccessSpelling.
Use StringRef's str() method instead of explicit std::string constructor.

Thanks for the review! I don't have commit access so I'd need someone to land this patch for me.

thanks a lot, looks like you've only uploaded the diff for your latest changes(e.g. changes to clang-doc are gone). you need to squash them and upload a single diff based at master.

Rebase and squash

This revision was automatically updated to reflect the committed changes.