Add a test for collection expression with ref struct element type #80593
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RikkiGibson
commented
Oct 13, 2025
| { | ||
| ReadOnlySpan<int> span3 = [3]; | ||
| ReadOnlySpan<int> span4 = [4]; | ||
| SpanCollection<ReadOnlySpan<int>> spans2 = [span3, span4]; |
There was a problem hiding this comment.
Should add a test to ensure that this collection can't be returned. I don't recall if we have a spec rule that makes this do the right thing for ref struct collection types.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to #77827
@CyrusNajmabadi haven't looked at your latest changes yet, but, wanted to make sure this test was preserved.
I think it would be reasonable to permit ref struct element type when CollectionExpressionTypeKind.ImplementsIEnumerable is used, and block it otherwise. I am suggesting this because this is the only way we know it can work today, and, if something changed from under us to make one of the other type kinds "start working", it feels like manual intervention would still be needed. (i.e., we would need to determine whether it's possible for us to generate code with reasonable semantics, and decide whether to permit or continue blocking.) That is better than potentially being hit by the same "generate bad IL" issue as
IEnumerable<ReadOnlySpan<int>>, but for some different type.It would also be reasonable to block it for all type kinds, though, until we see a more compelling use case.