Looks like suppression operator is allowed but only in some cases, presumably only a coincidence because in those other cases parser couldn't handle it, we didn't have an explicit check. How should we approach this?

        _= o is 1!; // ok (error with this change)
        const int i = 1;
        _= o is i!; // error

Looks like suppression operator is allowed but only in some cases [...]How should we approach this?

Given that a suppression in such place is nonsense, I think we can just disallow and treat the old behavior as a bug. We'd document the (minor) break just in case.

I've seen is null! usages but it's just wrong and misleading. I suppose we need compat council sign off on this.
Where should we document the breaking change, post VS2019? And what version we're targeting for the fix?

Will start email thread with compat council.
This would be documented in a new file for DotNet 6, similar to this one from DotNet 5: https://github.com/dotnet/roslyn/blob/main/docs/compilers/CSharp/Compiler%20Breaking%20Changes%20-%20DotNet%205.md

Sorry for the delay. Before I send the email out, let's clarify what is the proposed scope of break. Is it just on number literals and null?

All literal expressions can be suppressed right now, wherever they appear in a constant/relational pattern. Only identifiers gave syntax errors previously because we couldn't parse ! after a type-like.

Note this PR doesn't cover the case where a subexpression is suppressed, we may need to descend into the expression more deeply.

Note this PR doesn't cover the case where a subexpression is suppressed, we may need to descend into the expression more deeply.

@jcouv This would probably have even less impact than the top-level case but I'm not sure if we want it.

I think we could flag the pattern binder and report on any suppression instead of walking down the whole thing again here.

case where a subexpression is suppressed

@alrz I'm not sure where we stand on subexpressions. Could we start with a couple of examples to clarify the discussion?

Both of these checks are not covered for subexpressions.

public class C {
    bool b;
    public void M() {
        
        if (this is { b: default }) {} // error
        if (this is { b: true! }) {} // proposed to flag as error
        
        if (this is { b: 0 == default }) {} // no error
        if (this is { b: 1 == 1! }) {} // no error

    }
}

I think it's fine to leave those last two line as "no error". Let's stick with the PR as scoped :-)

@dotnet/roslyn-compiler for a second review. Thanks

/azp run

CI integration legs won't pass until #55681 is merged.

/azp run