[llvm] [AsmParser][NFCI] Restructure DiagnosticPredicate (PR #126653)

[Sergei Barannikov via llvm-commits]

================
@@ -198,21 +192,36 @@ enum class DiagnosticPredicateTy {
 // This is a light-weight alternative to the 'NearMissInfo' approach
 // below which collects *all* possible diagnostics. This alternative
 // is optional and fully backward compatible with existing
-// PredicateMethods that return a 'bool' (match or no match).
-struct DiagnosticPredicate {
-  DiagnosticPredicateTy Type;
-
-  explicit DiagnosticPredicate(bool Match)
-      : Type(Match ? DiagnosticPredicateTy::Match
-                   : DiagnosticPredicateTy::NearMatch) {}
-  DiagnosticPredicate(DiagnosticPredicateTy T) : Type(T) {}
-  DiagnosticPredicate(const DiagnosticPredicate &) = default;
+// PredicateMethods that return a 'bool' (match or near match).
+class DiagnosticPredicate {
+  enum class PredicateTy {
+    Match,     // Matches
+    NearMatch, // Close Match: use Specific Diagnostic
+    NoMatch,   // No Match: use `InvalidOperand`
+  } Predicate;
+
+public:
+#if __cplusplus >= 202002L
+  using enum PredicateTy;
+#else
+  static constexpr PredicateTy Match = PredicateTy::Match;
+  static constexpr PredicateTy NearMatch = PredicateTy::NearMatch;
+  static constexpr PredicateTy NoMatch = PredicateTy::NoMatch;
+#endif
----------------
s-barannikov wrote:

> I'm not sure what this is referring to on the `enum class` vs `enum` question.

The current approach looks good to me (`enum class` wrapped in a class).
But I'm not opposed to ordinary `enum` (inside a class), we've lived with it for quite some time. Again, it is somewhat different from ParseStatus, which is used extensively and in different contexts.
As for the proposed change, I guess it's your call whether we want extra type safety or not. I'll be happy with any decision.


https://github.com/llvm/llvm-project/pull/126653