-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Fix Color Color const field initialization accessing the Color type #68283
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
Changes from all commits
536c413
b145850
b896c53
78ab599
db11e2a
136e10e
3aa6500
d941af1
4f216e0
c4f3c8f
0a36d41
319d714
a2ecc0c
c27d5b9
06cbfea
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7547,6 +7547,11 @@ private BoundExpression BindLeftIdentifierOfPotentialColorColorMemberAccess(Iden | |
| Debug.Assert(!leftType.IsDynamic()); | ||
| Debug.Assert(IsPotentialColorColorReceiver(left, leftType)); | ||
|
|
||
| if (leftSymbol is SourceFieldSymbolWithSyntaxReference fieldLeft) | ||
| { | ||
| ConstantFieldsInProgress.RemoveIfLastDependency(fieldLeft); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I still find the approach to adjust/fixup the A cycle should be detected. Instead emit fails with the following error: I prefer an alternative approach that avoids premature binding of the value. It is implemented in #80978.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like your PR more than this one, it does the job more cleanly. We can close this one out unless the other PR doesn't go anywhere
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's wait for it to go through code review process |
||
| } | ||
|
|
||
| // NOTE: ReplaceTypeOrValueReceiver will call CheckValue explicitly. | ||
| boundValue = BindToNaturalType(boundValue, valueDiagnostics); | ||
| return new BoundTypeOrValueExpression(left, | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
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.
It is not obvious to me why only these symbols get special treatment. #Closed
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.
I guess that is because
ConstantFieldsInProgresstracks only these symbols.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.
However, it is not obvious to me that all affected scenarios are going to be handled if we apply this condition here.
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 only symbols that encounter this bug are fields, and this is the only type that is being tracked by
ConstantFieldsInProgressas you said. What kind of affected scenarios are you considering could be missed?