Compiler chooses params span overload in expression trees leading to errors

[ericstj]

Version Used:
4.11.0-2.24268.2+b9c35f1021d2d9d40521474c388d49ee7580ec98

Steps to Reproduce:

1. Call an API that has both params [] and params span overloads from an expression.

Minimal repro: exprSpan.zip

(sharplab doesn't yet have params span feature)

This could be seen as a source-breaking change for folks if they hit in conjunction with seeing new params span overloads for framework APIs. That's what happened here dotnet/efcore@dae7d42

Diagnostic Id:
CS8640, CS9226

Expected Behavior:
No error

Actual Behavior:

C:\scratch\exprSpan\Program.cs(8,51): error CS8640: Expression tree cannot contain value of ref struct or restricted type 'ReadOnlySpan'.
C:\scratch\exprSpan\Program.cs(8,51): error CS9226: An expression tree may not contain an expanded form of non-array params collection parameter.

[CyrusNajmabadi]

Oh that's interesting. And something we didn't consider when we had the intuition of "calling the span version is always better" :) This is def worth bringing to LDM to discuss.

[jaredpar]

@AlekseyTs this seems a potentially problematic case. Expression trees can't work with the new overloads but it's also quite logical for them to bind to them. Not sure that we have any precedence for this in the language. Definitely have cases where we say an expression tree can't use a feature but this is more we need it to change binding within expression trees. Don't have any good intuition on how to solve this.

[AndriySvyryd]

If the behavior won't be changed, consider adding an analyzer that could fix all of these instances.

[333fred]

Discussed in LDM on the 12th and 17th.

[AlekseyTs]

From https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-06-17.md#conclusion:

Do not change the compiler. Improve the error reporting experience.

From https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-06-17.md#params-span-breaks:

We do think we should invest a bit more in the error experience; having the compiler detect when such an overload is used in an expression tree and issue a specific diagnostic, and having the IDE offer to add an explicit array creation will go a long way to making the experience understandable.

[AlekseyTs]

It looks to me that we already produce a unique enough error message for the scenario. Specifically, I am referring to

error CS9226: An expression tree may not contain an expanded form of non-array params collection parameter.

It is true that the error is not limited to span scenarios, but I think that the suggested IDE fix will be helpful for users in non-span scenarios as well.

[AlekseyTs]

Moving to IDE to offer the suggested fix.

[AlekseyTs]

@CyrusNajmabadi Could you please route this issue accordingly? Add the right labels, etc.