This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Get rid of llvm::Optional in Remote- and LocalIndexRoot; NFC
ClosedPublic

Authored by kbobyrev on Oct 20 2020, 11:48 PM.

Diff Detail

Event Timeline

kbobyrev created this revision.Oct 20 2020, 11:48 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 20 2020, 11:48 PM
kbobyrev requested review of this revision.Oct 20 2020, 11:48 PM

I'm a little concerned by this, not sure if Expected and Optional play nicely with rvo. If the compiler can't optimise it's potentially a 256 byte memcpy in the return, granted that would still be cheaper than dynamic allocation. However it would most likely be faster if the functions took a reference to the SmallString (or more likely SmallVectorImpl<char>) and returned an llvm::Error or bool.

Sorry I don't really follow what we are gaining by changes from string to SmallString. Could you explain if I am missing something?

But I think it makes sense to get rid of Optionals in the Marshaller for {Local,Remote}IndexRoot, as there's no difference between None vs empty for them (I think).

clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
59

we seem to be explicitly creating a smallstring out of std::string. and all of the usages of remoteindexroot seems to be just using a stringref. why are we doing this exactly? to make sure the addition of trailing separator below doesn't do reallocation ? If so this only happens once per each remote-index, right? Is it really worth all the hassle?

same for LocalIndexRoot.

385

don't we end up creating a string here anyways?

(same below)

clang-tools-extra/clangd/index/remote/marshalling/Marshalling.h
99–100

what's the difference between None and empty string here ? Can we just get rid of Optional?

kbobyrev updated this revision to Diff 299934.Oct 22 2020, 5:28 AM
kbobyrev marked 3 inline comments as done.

Get rid of llvm::Optional in local and remote paths.

kbobyrev retitled this revision from [clangd] Use SmallString instead of std::string in marshalling code; NFC to [clangd] Get rid of llvm::Optional in Remote- and LocalIndexRoot; NFC.Oct 22 2020, 5:28 AM
kadircet accepted this revision.Oct 22 2020, 11:43 AM
kadircet added inline comments.
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
58–59

nit: if(!is_separator(this->RemoteIndexRoot.back(), posix)) same below.

This revision is now accepted and ready to land.Oct 22 2020, 11:43 AM
kbobyrev updated this revision to Diff 300079.Oct 22 2020, 12:42 PM
kbobyrev marked an inline comment as done.

Resolve post-LGTM comment.

kbobyrev updated this revision to Diff 300080.Oct 22 2020, 12:47 PM

Rebase on top of master

This revision was landed with ongoing or failed builds.Oct 22 2020, 12:49 PM
This revision was automatically updated to reflect the committed changes.
ArcsinX added inline comments.
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
60

I know this already commited, but maybe we could use llvm::sys::path::is_separator instead of is_separator to be consistent with other function calls from llvm::sys::path namespace in this file.

P.S. llvm::sys::path::is_separator checks a single char, but llvm::sys::path::get_separator returns string. Can not understand why. Could there be a multi-char separator in the future?

kbobyrev added inline comments.Oct 23 2020, 2:18 AM
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
60

I think it'd be better to strip llvm::sys::path elsewhere and simply rely on ADL. Spelling llvm::sys::path:: twice does not really add much value and simply takes more space. I'll send a separate patch.

kadircet added inline comments.Oct 23 2020, 2:19 AM
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
60

Because llvm::sys::path::get_separator returns a null terminated string.

Could there be a multi-char separator in the future?

I would expect the person doing such a change to also update is_separator.

ArcsinX added inline comments.Oct 23 2020, 2:27 AM
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
60

Because llvm::sys::path::get_separator returns a null terminated string.

Why does not llvm::sys::path::get_separator() return a single char instead of a null-terminated string?

kadircet added inline comments.Oct 23 2020, 3:24 AM
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
60

Why does not llvm::sys::path::get_separator() return a single char instead of a null-terminated string?

Probably to make composition with + easier. But one would need to dig-up the git blame and see if there are any other reasons I suppose, or ask the authors as mine is merely a guess :D