This is an archive of the discontinued LLVM Phabricator instance.

Use std::nullopt_t instead of NoneType (NFC)
ClosedPublic

Authored by kazu on Nov 22 2022, 7:19 PM.

Details

Summary

This patch replaces those occurrences of NoneType that would trigger
an error if the definition of NoneType were missing in None.h.

To keep this patch focused, I am deliberately not replacing None with
std::nullopt in this patch or updating comments. They will be
addressed in subsequent patches.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

Diff Detail

Event Timeline

kazu created this revision.Nov 22 2022, 7:19 PM
Herald added a reviewer: rafauler. · View Herald Transcript
Herald added a reviewer: Amir. · View Herald Transcript
Herald added a reviewer: maksfb. · View Herald Transcript
Herald added a reviewer: NoQ. · View Herald Transcript
Herald added a reviewer: njames93. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
kazu requested review of this revision.Nov 22 2022, 7:19 PM
Herald added projects: Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptNov 22 2022, 7:19 PM
DavidSpickett added a subscriber: DavidSpickett.

lldb parts LGTM.

dblaikie accepted this revision.Nov 23 2022, 10:35 AM

Sounds good to me, thanks!

This revision is now accepted and ready to land.Nov 23 2022, 10:35 AM
MaskRay accepted this revision.Nov 23 2022, 11:49 AM
MaskRay added inline comments.
clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
218

A maintainer might want to check the uses. Having 3 constructors looks confusing to readers.

This revision was landed with ongoing or failed builds.Nov 23 2022, 2:16 PM
This revision was automatically updated to reflect the committed changes.

This patch breaks llvm::StringSet equality.
The following code would no longer compile:

llvm::StringSet LHS;
llvm::StringSet RHS;
bool equal = LHS == RHS;

Such code might be used as gtest assertions like EXPECT_EQ(LHS, RHS).
@kazu Do you think we should address this by providing an equality operator for the StringSet?
I was thinking of adding this:

bool operator==(const StringSet &RHS) const {
  if (Base::size() != RHS.size())
    return false;

  // For StringSets we only need to check the keys.
  for (const auto &KeyValue : *this) {
    if (RHS.find(KeyValue.getKey()) == RHS.end())
      return false;
  }
  return true;
};

Do you think we should backport this to release/16.x, given that this could break downstream users and that llvm-16.0.0 is not released yet?

Oh, I forgot to mention why this change breaks the equality operator of llvm::StringSet. It's because the StringMap::operator== will try to compare the value as well, which is of type std::nullopt_t and that has no equality comparison operator.
Previously, the enum class NoneType has a default one.

Hm, it would be easier to use llvm::StringMap<decltype(std::monostate)> instead of std::nullopt_t, or some adhoc empty struct.

Oh, I forgot to mention why this change breaks the equality operator of llvm::StringSet. It's because the StringMap::operator== will try to compare the value as well, which is of type std::nullopt_t and that has no equality comparison operator.
Previously, the enum class NoneType has a default one.

Since std::unordered_set and counterparts like absl::flat_hash_set provide operator==, I think providing StringMap::operator== is fine. I don't think whether the operation is commonly used, though.