-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collection expressions: align ConversionsBase.GetCollectionExpressionTypeKind() with spec #70975
Conversation
…TypeKind() with spec
@@ -1638,23 +1638,14 @@ internal static CollectionExpressionTypeKind GetCollectionExpressionTypeKind(CSh | |||
return CollectionExpressionTypeKind.Array; | |||
} | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the spec explicitly say that MD arrays are not valid targets?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MD arrays are not valid targets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added clarification in dotnet/csharplang#7734.
@333fred, @RikkiGibson Please review |
@333fred, @RikkiGibson Please review |
1 similar comment
@333fred, @RikkiGibson Please review |
@RikkiGibson For the second review |
I'll try and take a look this afternoon. Thanks |
@@ -128,7 +191,7 @@ private BoundExpression VisitArrayOrSpanCollectionExpression(BoundCollectionExpr | |||
|
|||
Debug.Assert(IsAllocatingRefStructCollectionExpression(node, collectionTypeKind, elementType.Type, _compilation)); | |||
arrayType = ArrayTypeSymbol.CreateSZArray(_compilation.Assembly, elementType); | |||
spanConstructor = ((MethodSymbol)_compilation.GetWellKnownTypeMember( | |||
spanConstructor = ((MethodSymbol)_factory.WellKnownMember( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: _factory.WellKnownMethod
eliminates the need to cast #ByDesign
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, we're using _factory.WellKnownMethod()
throughout this file, and in a number of other callsites in LocalRewriter
where we could cast the result to MethodSymbol
. Given that, I'll leave as-is, to reduce the churn.
@@ -674,7 +674,7 @@ void checkConstraintLanguageVersionAndRuntimeSupportForConversion(SyntaxNode syn | |||
} | |||
else | |||
{ | |||
if ((collectionTypeKind is CollectionExpressionTypeKind.ArrayInterface or CollectionExpressionTypeKind.List) || | |||
if ((collectionTypeKind is CollectionExpressionTypeKind.ArrayInterface) || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to check presence of these members when collectionTypeKind
is CollectionInitializer
? #ByDesign
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should only be using these methods for collection initializers when the target is List<T>
, and in those cases, we'll bind to the methods in initial binding.
IL_0017: ldsfld "System.Runtime.CompilerServices.CallSite<System.Action<System.Runtime.CompilerServices.CallSite, System.Collections.Generic.List<object>, dynamic>> Program.<>o__0.<>p__0" | ||
IL_001c: brtrue.s IL_005c | ||
IL_001e: ldc.i4 0x100 | ||
IL_0023: ldstr "Add" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this dynamically invoking Add
? I'm not sure I understand why codegen is changing in this test. #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is dynamically invoking Add()
. (This implementation corresponds to the collection initializer approach - see sharplab.io.) We don't optimize if the elements include dynamic
values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I was surprised is that the codegen before didn't appear to be optimized. Is that codegen from before actually optimized and that's why it's changing now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the dynamic case was optimized previously.
IL_0015: stloc.2 | ||
IL_0016: ldloc.0 | ||
IL_0017: ldloc.2 | ||
IL_0018: callvirt "void System.Collections.Generic.List<object>.Add(string)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uh..which one? :) #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This uses the specialized List<object>.Add(string)
rather than List<object>.Add(object)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done review pass. Had a few minor comments and questions.
Update
ConversionsBase.GetCollectionExpressionTypeKind()
to check collection expressions for the conversions as defined in specification only.The effect of this change is that recognizing whether to optimize
List<T>
andImmutableArray<T>
is now handled in lowering rather than initial binding, and the requirements for optimizing those types is tightened:List<T>
are no longer applied if there aredynamic
elements, andImmutableArray<T>
are only applied if the type has a[CollectionBuilder]
attribute.Fixes #70880