Use Pattern Matching suggestion gives faulty code

[Joy-less]

Version Used: C# 12

Steps to Reproduce:

1. Paste the following code into Visual Studio:

public class Program {
    public class Cat {
    }
    public static void Main() {
        Cat Cat = new();
        object Object = Cat;
        
        // Suggestion: IDE0083: Use Pattern Matching
        if (!(Object is Cat)) {
            
        }
    }
}

2. If you accept the suggestion, it corrects your code to:

if (Object is not Cat) {
    
}

which gives you a compilation error: (line 14, col 21): A constant value is expected

Diagnostic Id: IDE0083

Expected Behavior:
No suggestion given.

Actual Behavior:
Faulty suggestion given.

Related discussion:
dotnet/csharplang#7980

[ghost]

Hey, I could take this, but I need some information.

I think in this case, you would try to remove the ambiguity by putting a more qualified name such as Program.Cat here, but I don't know if there is logic dedicated to handling this type of syntax generation. If there is, I would like to know more.

Also, I would like to know how one would manage the logic of only putting enough qualification to the name to resolve the ambiguity, but not necessarily the fully qualified one as it might not be fully necessary.

[CyrusNajmabadi]

I think in this case, you would try to remove the ambiguity by putting a more qualified name such as Program.Cat here

That seems reasonable. Or we could block this case in the analyzer.

but I don't know if there is logic dedicated to handling this type of syntax generation

You can use the extension GenerateNameSyntax for this purpose.

Also, I would like to know how one would manage the logic of only putting enough qualification to the name to resolve the ambiguity, but not necessarily the fully qualified one as it might not be fully necessary.

GenerateNameSyntax will add an annotation to the node asking our simplifier to simplify it.

[ghost]

I think in this case, you would try to remove the ambiguity by putting a more qualified name such as Program.Cat here

That seems reasonable. Or we could block this case in the analyzer.

but I don't know if there is logic dedicated to handling this type of syntax generation

You can use the extension GenerateNameSyntax for this purpose.

Also, I would like to know how one would manage the logic of only putting enough qualification to the name to resolve the ambiguity, but not necessarily the fully qualified one as it might not be fully necessary.

GenerateNameSyntax will add an annotation to the node asking our simplifier to simplify it.

I experimented using generator.NameExpression which ends up doing that and it does give me the fully qualified name which works, but now I am hitting a second issue: the simplifier reduces it back to the same ambiguous name.

So it seems that there's a part of this where the simplification is uneeded, but now comes the question of how this can be done? It might be possible to manually walk up the names until there's no collisions manually, but now the question becomes how do I know a given name collides?

[CyrusNajmabadi]

the simplifier reduces it back to the same ambiguous name.

The simplifier should be fixed as part of the PR. Thanks :)

[CyrusNajmabadi]

but now the question becomes how do I know a given name collides?

The simplifier can check for this with the name choices it makes. Specifically looking to see if the simple name binds to something like this in a context like this and jsut blacklisting it.