This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Value initialize SymbolIDs
ClosedPublic

Authored by kadircet on Oct 29 2020, 8:06 AM.

Details

Summary

We were default initializing SymbolIDs before, which would leave
indeterminate values in underlying std::array.

This patch updates the underlying data initalization to be value-init and adds a
way to check for validness of a SymbolID.

Diff Detail

Event Timeline

kadircet created this revision.Oct 29 2020, 8:06 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 29 2020, 8:06 AM
kadircet requested review of this revision.Oct 29 2020, 8:06 AM
sammccall added inline comments.Oct 29 2020, 8:10 AM
clang-tools-extra/clangd/index/SymbolID.h
57

I'm not a big fan of LLVM's habit of calling the sentinel value "invalid".

Consider SourceLocation - one can construct invalid source locations that are isValid() (add an offset longer than the file) and SourceLocation() most commonly means "there is no location associated" rather than "we have bad data".

WDYT about calling this "isNull" (and possibly defining operator bool())?

kadircet updated this revision to Diff 301678.Oct 29 2020, 10:47 AM
kadircet marked an inline comment as done.
  • change invalid -> null.
  • add an implicit bool conversion operator.
  • update apis returning optional<symbolid>s.

Note that all the functional changes are in SymbolID.h, rest is api updates.

nridge added a subscriber: nridge.Oct 31 2020, 3:58 PM

Would it have been possible to disallow default-constructing SymbolID altogether, and preserve the ability to represent "an always-valid symbol id" (SymbolID) vs. "a maybe-valid symbol id" (Optional<SymbolID>) as distinct types in the type system?

sammccall accepted this revision.Oct 31 2020, 6:12 PM

Would it have been possible to disallow default-constructing SymbolID altogether, and preserve the ability to represent "an always-valid symbol id" (SymbolID) vs. "a maybe-valid symbol id" (Optional<SymbolID>) as distinct types in the type system?

Absolutely, except where it matters`sizeof(SymbolID)==8` and sizeof(Optional<SymbolID>)==16.
I think the trigger here was SymbolID Ref::Container - we can't afford to use Optional there.
We could come up with some special-case solution for that and use Optional elsewhere - I don't really feel strongly about it.

clang-tools-extra/clangd/AST.h
66–67

probably want to be a bit more specific about the possibility of returning null (and below)

clang-tools-extra/clangd/index/SymbolID.h
57

just return *this == SymbolID()?

58

nit: I think you want this to be explicit. Note that if(x) will perform an explicit cast if needed

58

this should be !isNull()!

This revision is now accepted and ready to land.Oct 31 2020, 6:12 PM

Would it have been possible to disallow default-constructing SymbolID altogether, and preserve the ability to represent "an always-valid symbol id" (SymbolID) vs. "a maybe-valid symbol id" (Optional<SymbolID>) as distinct types in the type system?

Absolutely, except where it matters`sizeof(SymbolID)==8` and sizeof(Optional<SymbolID>)==16.
I think the trigger here was SymbolID Ref::Container - we can't afford to use Optional there.

Good point!

kadircet updated this revision to Diff 302230.Nov 2 2020, 2:37 AM
kadircet marked 4 inline comments as done.
  • Mention possibility of returning null SymbolIDs in comments.
  • Mark bool conversion operator explicit, fix the bug in returned value. (and run tests :))
clang-tools-extra/clangd/index/SymbolID.h
58

oopsy, should've ran tests :D

This revision was landed with ongoing or failed builds.Nov 2 2020, 2:43 AM
This revision was automatically updated to reflect the committed changes.