code fix of IDE0002 produces invalid code when a constant has same name as its type

[aayjaychan]

Version Used:
Visual Studio 2019 16.6.2

Steps to Reproduce:

using System;

namespace N
{
    public class C
    {
        public const DateTimeKind DateTimeKind = System.DateTimeKind.Utc;
    }
}

Expected Behavior:
no suggestion is provided

Actual Behavior:
code fix suggested, which simplifies code to

using System;

namespace N
{
    public class C
    {
        public const DateTimeKind DateTimeKind = DateTimeKind.Utc;
    }
}

which causes error

CS0110 The evaluation of the constant value for 'C.DateTimeKind' involves a circular definition

[manfred-brands]

The compiler gives the error, but VS2022 seems to infer the type correctly:

Should the compiler also be able to infer this?

[Rabadash8820]

Just ran into this myself, following the codefix for CA1707: Identifiers should not contain underscores

// Yields warning CA1707, with a codefix in Visual Studio
public const BindingFlags BINDING_FLAGS = BindingFlags.DeclaredOnly | BindingFlags.Public | BindingFlags.Instance;

// Code after fix, now yields compiler error CS0110, even though syntax highlighting is still correct in Visual Studio
public const BindingFlags BindingFlags = BindingFlags.DeclaredOnly | BindingFlags.Public | BindingFlags.Instance;

[CyrusNajmabadi]

@jaredpar do you know why the Color Color lookup rules aren't coming into play here? It feels like this should be entirely legal:

public const DateTimeKind DateTimeKind = DateTimeKind.Utc;

Note: if you change const to static readonly, then everything is fine. So it's only about const. I have a feeling the const evaluation rules are doing something wrong and not appropriately applying Color Color to realize that DateTimeKind.Utc has no reference to the const itself, but is a a reference to the enum member.

I'm actually going to give to the compiler for now as my gut is this is a bug on that side.

If compiler genuinely feels this is correct behavior, this can come back to IDE to address updating the analyzer to understand this case.

[jaredpar]

I agree the spec seemingly allows for this:

In a member access of the form E.I, if E is a single identifier, and if the meaning of E as a simple_name (§12.7.4) is a constant, field, property, local variable, or parameter with the same type as the meaning of E as a type_name (§8.8.1), then both possible meanings of E are permitted

In this case E is DateTimeKind and it is a constant and the rest of the rules match.

@AlekseyTs, @cston do you agree this should be allowed by the spec?

[AlekseyTs]

do you agree this should be allowed by the spec?

Yes, it looks like the scenario should be allowed by the specification. Though, it looks like native compiler doesn't allow it either.
Why is this happening? Before we can figure out if the "Color.Color" relaxation should apply, compiler actually needs to bind the identifier in a non-relaxed form. While we are doing this, we record the reference as a circular reference, even though later on we reclassify it as a possible type reference. I guess, we could make this scenario work, but that would require complicating the cycle detection machinery and introducing a risk of failing to detect a cycle in some scenarios.