[Analyzer Proposal]: Avoid `Enum.HasFlag`

[Youssef1313]

Background and motivation

Enum.HasFlag was historically very problematic performance-wise. The situation has improved a lot in .NET Core 2.1 and many switched to using it again instead of the bitwise AND for readability.

However, per #55455 (comment):

Note that this optimization is not guaranteed to kick in. The optimization won't kick in Debug builds, in tier 0 JIT, or when the method is too big.

If the optimization isn't guaranteed to happen, I think it would make sense to still avoid it?

API Proposal

A new analyzer that will report a diagnostic when using x.HasFlag(y) where x and y are known to be of the same enum type at compile-time. There should be a code-fix that turns this to (x & y) != 0

API Usage

N/A

Alternative Designs

No response

Risks

No response

[alexrp]

#89348

[alexrp]

cc @EgorBo

[Youssef1313]

Oh. That's very recent. Is the optimization now guaranteed to always happen? If that is the case, then I think #55455 should be reconsidered 😄

[stephentoub]

Is the optimization now guaranteed to always happen?

No, but even if it doesn't (eg debug, or methods so long they stop getting optimized) I don't want to encourage devs in general to code around it. From my perspective, it's primarily a style issue at this point and not something for us to be adding an analyzer for in the SDK, in either direction.