That would be the non-generic IEnumerable case, right? So that's like converting an object~ element type to the target element type, there's no nullability check that needs to be done there? #Resolved

CollectionExpressionTypeKind.ImplementsIEnumerable represents any collection initializer type where the type implements IEnumerable and elements are added through Add().

This PR does not handle nullability analysis for those cases. There is a separate item in #68786.

• Checking conversion of elements to iteration type for collection initializer types

Do we actually need to dig into the expression here, instead of just visiting the statement, for the verifier to pick it up? #Resolved

NullableWalker only visits the expression within the BoundExpressionStatement of spread.IteratorBody. (The containing BoundExpressionStatement is only there to allow sharing code in binding between foreach and .. since the foreach infrastructure expects the body to be a statement.)

OK, sounds like if we visited the statement here, then we would fail verification because NullableWalker did not also visit that statement.

It looks like we are assuming the iteratorBody is something that would be convertible to the elementType? But I thought it could represent a call to a void-returning Add method, for example. #Resolved

The Add() cases are not handled in this PR. For those cases, elementType.HasType == false so we shouldn't reach this code path.

I don't find the connection between elementType.HasType and the shape of the spread IteratorBody straightforward to follow. It seems like there are several places where we dig into the IteratorBody and expect to get an expression which meets certain assumptions. Perhaps it would be helpful to add some extension(s) to BoundCollectionExpressionSpreadElement which implies and verifies the assumption the developer is making.

Also, it feels like using a name like targetElementType instead of elementType would make this code a little easier to follow, to be clear we are not talking about the element type of the spread operand itself.

That said, none of the above changes need to happen in this PR.

Thanks. I've renamed elementType to targetElementType. We can consider adding methods to BoundCollectionExpressionSpreadElement as needed in separate PRs.

What is being analyzed to yield this warning? Are we actually converting the b to IEnumerable<object> before enumerating in the bound tree and warning on that?

It looks like the comment refers to ab = [..a, ..b] in TypeInference_Spread_08.

In that test, b has type IEnumerable<string?>[] and the target collection has type IEnumerable<object!>[].

NullableWalker.VisitCollectionExpression is reporting the warning from the implicit conversion of the element of the spread element expression, with type IEnumerable<string?>, to the element type IEnumerable<object!> of the target collection.

Parking comment here, but it relates to a test below. I think we can remove the comment in SpreadNullability_SplitExpression. #Closed

Consider adding the converse scenario, where the elements are not-null and the target collection allows for null elements:

                        IEnumerable<string> x = [""];
                        IEnumerable<object?> y = [..x]; // no warning
``` #Closed

Do we have a test where the spread operand is more than a simple local? For instance M(x), which could produce nullability warnings of its own. #Closed

It looks like the operand in test Spread_Nullable_09 is not producing warnings of its own. It sounded like Julien was asking for an F() which warns about a possible null argument, for example.

Added case.

It looks like a case like int[] x = [..(int[]?)null] is handled by the VisitForEachExpression itself? Since we would be visiting a loop like foreach (var elem in (int[]?)null) { ... }? #Resolved

Yes, the top-level nullability of the expression being spread is handled in VisitForEachExpression(). For an example test, see CollectionExpressionTests.SpreadNullability.