Note that DefiniteAssignment has a behavior where once a diagnostic is reported on a variable, it will not report a diagnostic on that variable again. So in order to verify that e.g. a diagnostic is produced or not in both branches, it's more reliable to just use a different variable in each branch.

node.LeftOperand is BoundConditionalAccess [](start = 33, length = 42)

This doesn't feel right. What if the left side is a cast on top of a null-conditional access? #Closed

There might be a need to change this to handle certain BoundConversions here, but the specification doesn't currently indicate that a ?? operand which is a cast containing a conditional access should do anything differently than today. However, it may be a good idea to change that. #Closed

I was unable to find scenarios where the LHS of a ?? is a BoundConversion where:

• there is no explicit cast
• there are no errors on the node
• Operand is a BoundConditionalAccess

Therefore, I put an assertion and a PROTOTYPE in the code for the moment.

When debugging the bootstrap failures I did experiment a fair bit with different scenarios to try and hit the assertion. If you have ideas for scenarios that would actually hit the assertion as written, that would be welcome.

When we start handling more kinds of containing expressions, I feel like the correct way to handle these conversion nodes is going to become more clear, so I'd like to punt it to the next PR (for ==/!=) if that is acceptable.
#Closed

I would expect to see a conversion on the left side for a scenario like this:

C c = null;
D d = c ?? default(D);

class C {}

struct D
{
    public static implicit operator D(C c) => default;
}

Make the c variable a conditionally-access method with a null, and we should be able to observe behavior.

In reply to: 595506242 [](ancestors = 595506242)

Could you please add a test where the left-hand side is an NVT of an enum type?