[PATCH] D71576: [c++20] Add deprecation warnings for the expression forms deprecated by P1120R0.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith closed this revision.
rsmith marked 4 inline comments as done.
rsmith added a comment.

Committed as rG4b0029995853fe37d1dc95ef96f46697c743fcad <https://reviews.llvm.org/rG4b0029995853fe37d1dc95ef96f46697c743fcad>.



================
Comment at: clang/lib/AST/Type.cpp:1865-1866
   // enumeration type in the sense required here.
   // C++0x: However, if the underlying type of the enum is fixed, it is
   // considered complete.
   if (const auto *ET = dyn_cast<EnumType>(CanonicalType))
----------------
rnk wrote:
> Is this C++11 comment still relevant? I assume that `isComplete` handles this case by returning true, and a forward decl can tell us if the enum is scoped.
I don't think this is useful -- and probably nor is the `isComplete` check. I'll look into this in a follow-up commit.


================
Comment at: clang/test/SemaCXX/warn-enum-compare.cpp:79
 
-  while (B1 == B2); // expected-warning  {{comparison of two values with different enumeration types ('name1::Baz' and 'name2::Baz')}}
-  while (name1::B2 == name2::B3); // expected-warning  {{comparison of two values with different enumeration types ('name1::Baz' and 'name2::Baz')}}
----------------
rnk wrote:
> It seems more technically correct to say that two values are being compared, but I don't see how to keep the diagnostic as well factored as you have it.
Yeah, I agonized over this a little, but while I agree with you, in the end I think it's not entirely wrong to talk about (eg) a comparing an int with a float, and the ambiguity between types and values there doesn't seem likely to actually be confusing -- I don't think the extra words help comprehension of the diagnostic. I'm happy to change it back, of course.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71576/new/

https://reviews.llvm.org/D71576