Debugger breakpoints cannot be set with patterns.

[CyrusNajmabadi]

1. I would expect to be able to set a breakpoint on a pattern member like x is Point { Left is Constant(0) }. i.e. on the Left is Constant 0 line. During debugging i would expect to be able to hover on Left and see what it actualy is.
2. I would expect to be able to set breakpoints on the case clauses of both switch statements with patterns and match/case case clause patterns.
3. I would expect to be able to set breakpoints on the expressions inside case clauses of match/case expressions.

[gafter]

There are no cases in the language today where you can set a breakpoint on a subexpression. You cannot set a breakpoint on a case clause today. So this is a feature request.

[CyrusNajmabadi]

Not true:

[CyrusNajmabadi]

There are no cases in the language today where you can set a breakpoint on a subexpression

The intent of breakpoint spans is to be able to set them on sequence points. However, the IDE has never been able to get a spec/API from the compiler side to actually specify what the sequence points are. So we've always attempted to reverse engineer it.

Any places where we don't support this today are not intentional omissions, but are due to mistakes trying to make these determinations.

Other places we support breaking on expressions: the components of a for statement. The expression of foreach statement. Many of the subexpressions inside a query expression (including from/let/join/where/select/orderby/group).

[tmat]

@CyrusNajmabadi Your lambda body example isn't actually an expression. It's a return statement as far as the debugger is concerned. When reasoning about sequence points you need to reason about the IL not the syntax representation. Currently the debugger doesn't support sequence points at places where evaluation stack is not empty. We would need to spill the stack in order to place a sequence point. This is a non-trivial feature request.

[gafter]

If you use an expression with a pattern as the body of a lambda, you will still be able to set a breakpoint there.

[CyrusNajmabadi]

Your lambda body example isn't actually an expression

To all users it is. And, afaict, from the language perspective it is. I'm not going to get in a semantics argument about this. I'm simply stating how users will want this to behave given the language feature and given how previous language features have worked.

When reasoning about sequence points you need to reason about the IL not the syntax representation

Great. We've been asking for such an API for apprx 10+ years. If you can get us one, i'll move us over to using it. But, for now, we go the syntax route because that's all we have :)

Currently:

1. we support expression breakpoints in many scenarios, regardless of what transforms happen, or waht the debugger finally sees.
2. users will want expression breakpoints in the cases i enumerated above.

That's the issue. How we go about actually making this happen is another matter altogether. But this bug is about tracking the feature deficiency vis as vis the breakpoint feature and the patterns feature :)

[tmat]

@CyrusNajmabadi I'm just pointing out that there is a difference between subexpressions and "top-level" expressions. We support placing breakpoints on the latter but not the former.

[gafter]

To be clear, I do not expect we will be supporting breakpoints inside patterns. The spec clearly leaves the order of evaluation of patterns unspecified.

[tmat]

Since similar feature request have been made previously I have filed a more general issue to track feature of placing breakpoint on an arbitrary expression: #22016. I would not hold my breath though expecting this feature to be implemented any time soon.