Create modernize-enum-from-macros check

[LegalizeAdulthood]

Bugzilla Link	27034
Version	unspecified
OS	All
CC	@EugeneZelenko,@Trass3r

Extended Description

Consider the following code:

#define RED 0
#define GREEN 1
#define BLUE 2

struct RGBColor { /* ... */ };

extern float getChannel(const RGBColor &color, int channel);

RGBColor blue;
float red = getChannel(blue, RED);

The macros are being used as an enumeration. This is best done by explicitly using an enumeration instead of int and a bunch of macros.

Create a check that identifies such macros disguised as enumerations and replaces them with an actual enum.

[LegalizeAdulthood]

A good first pass of this feature would be to simply flag such macros as possible enums in disguise.

[Trass3r]

Very basic detection is available in https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-macro-usage.html.
But there's no specific logic to check for enumerations, let alone fix-its.

[LegalizeAdulthood]

I looked at the documentation for that check and honestly I can't tell specifically what it does from the description.

"Finds macro usage that is considered problematic because better language constructs exist for the task."

Such as....?

This description is so vague and there are no examples given, so I have no idea what this check is going to flag as "problematic".

[Trass3r]

Well the implementation is very basic at the moment, warning about pretty much every macro, see 40599.
I have a PoC implementation of a heuristic enum check but it's tricky to reduce false positives since you're operating on a token level there (how do you determine that the right-hand side is actually a value and constexpr).

[LegalizeAdulthood]

Yes, I see. I commented on the other bug. Macros are just a pain and doing any kind of guidelines checks around them is probably going to involve some serious work.

For the simple case I was outlining in this feature request, I expected that the replacement text would be regex matched against a digit string and then the value parsed and compared against subsequent macros on consecutive lines to identify the enum pattern.

[Trass3r]

Tell me about it. In real-world code that quickly goes south though:
#define R 1
#define B R
#define G (R | 2)
#define W ( 4 | R
| B )

[LegalizeAdulthood]

Well, particularly when the preprocessor is involved, it's easy to come up with torture examples. I don't expect this check to drill through that mess and some up with any sort of recommendation. In particular I would expect the check to stop caring as soon as it saw

#define B R

In this case the replacement tokens are not a constant, even though it will ultimately expand to a constant. I don't know if clang's preprocessor handling is going to let you see that 'B' is defined as 'R', which in turn is defined as '1' or if it's just going to tell you that 'B' expands to '1'.

For this check, you'd definitely want to know the former and not the latter.

When you get into detailed checks around the use of the preprocessor, I would not be surprised at all if the preprocessing mechanism has to be enhanced in order for some of this knowledge to be exposed.

[Trass3r]

I targeted the common prefix naming convention. Like in all the Windows headers, WM_* etc. Works quite well but catches a few unintended macros.

[LegalizeAdulthood]

Oh, that's a good idea! A simple heuristic that is likely to identify most of the cases.

[LegalizeAdulthood]

@Trass3r What I settled on is literal tokens only, possibly with unary prefix +, - or ~.