Not sure if the new check should be moved toCanSupportObjectInitializer?

i'm fine with either approach.

I do not think this is 100% accurate. I suggest removing this statement. What is the "correct" lifetime region depends on particular situation. #Closed

Debug.Assert(operation.Parent is SimpleAssignmentOperation assignment

Is this code still reachable? #Closed

Good catch. Restored exception.

cloned = visitedInstance

Is this also implementing supprt forwith on structures? It doesn't look like PR's description mentions that. #Closed

Yes, I noticed that for structures we were producing an invalid operation because no clone method is available. I added a test and fixed it here, but forgot to add to description.

Updated description.

Also includes fix forwith on pointer types.

I'm thinking this fix may be incorrect though :-/ Do we need to capture it instead? I'll add some tests with control flow and invocations on value types....

Never mind. I recall thatHandleObjectOrCollectionInitializer handles that.
I'll add the tests though

string

Why use name as the key instead of the property symbol? #Closed

Is it possible to have duplicate names in some error situations?

Name seems simpler.
Yes, it's possible to have duplicate names in error scenarios and this code handles that (we ignore the return value fromAdd andRemove)

Name seems simpler.
Yes, it's possible to have duplicate names in error scenarios and this code handles that (we ignore the return value from Add and Remove)

Does that mean that we will ignore the fact that the duplicate property isn't initialized? And perhaps not include its copy into the AnonymousObjectCreationOperation, thus failing to match the shape of the constructor?

string

Using names as keys feels fragile, I think we should use property symbols for that. #Closed

set.Remove(propertyReference.Property);

It looks like we are making an assumption that a property that we get here belongs to the Anonymous Type that is cloned (otherwise we might be allocating captures that won't be used at the end). I think it is a valid assumption to make, but it might be worth adding an assert about that several lines above, where we asert other aspects of each property reference. Based on that assumption, consider if it is worth reducing the amount of HashSet operations (additions/removals) that we perform. For example, instead of first adding all properties into the set and then removing those that we run into, we could start with an empty set, add properties that we run into and at the end check if the count of items in the set equals to the count of properties in the type. #Closed

initializerBuilder

Consider adding an assert that the amount of initializers matches the amount of properties. #Pending

return true;

This is for scenarios like WithExprOnStruct_ControlFlow_WithCoalescingExpressionForValue so that the verifier won't complain about the long-lived capture with "Operation [{operationIndex}] in [{getBlockId(block)}] uses capture [{id.Value}] from another region. Should the regions be merged?" assertion above.

This would be more informative if the memo actually included the actual ids so that we could look at the graph and confirm that we indeed want to suppress the assertion. #Closed

nit: it feels like the&& can be collapsed into a single recursive pattern and this can be inlined at the call site :)

nit: it feels like in this scenario we could use an ArrayBuilder which maps theAnonymousTypePropertySymbol.MemberIndexOpt.Value to aBoundLocal?. Also could consider exposing a member on AnonymousTypePropertySymbol likeint MemberIndex => _index. #Resolved

Made the change. Thanks

Thank you for this. #Closed

nit: it feels like it's possible to avoid storing to temps when the assignments occur in the same order as the constructor parameters, similar to the way method call arguments are rewritten during lowering. However, I don't think it's necessary to implement this optimization in this PR. #WontFix

Agreed. Also, the cases where this optimization could actually play out aren't the common case so it seems fine to punt.

Thanks for this. It helped me review this PR and I'm sure it will help future readers. #Closed