-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Field-backed properties: support partial properties with auto-implemented accessors and with initializers #74959
Conversation
b0f42f7
to
45cb105
Compare
22ba653
to
ae4b17a
Compare
a8eeabf
to
28c7686
Compare
Test failure log
There is no way that a fuzzer I added like a year ago is now finding a real (but likely transient) problem..right? |
src/Compilers/CSharp/Portable/Symbols/Source/SourceMemberContainerSymbol.cs
Outdated
Show resolved
Hide resolved
// When calling through the SemanticModel, partial members are not | ||
// necessarily merged when the containing type includes a primary | ||
// constructor - see https://github.com/dotnet/roslyn/issues/75002. | ||
else if (_containingType.PrimaryConstructor is { }) |
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 feels like too direct of a workaround for a bug. Basically, it's not clear that this is the only case where we would be accessing this information before containing type members are complete.
I think if this API must work while the symbol is in this state, then it would make sense to:
Debug.Assert(_containingType.PrimaryConstructor is { })
, so that we detect any test scenarios which tell us more cases where this is occurring.- Always return the same value when
!_containingType.AreMembersComplete
, regardless of whether_containingType.PrimaryConstructor is { }
. Whether the right thing is for it to always beDeclaredAutoPropertyInfo
or_lazyMergedAutoPropertyInfo!
, I am not sure. It is essentially an internal error recovery scenario, for a case where the symbols are in an invalid state.
I was also wondering, did you consider using a similar pattern as we use for BoundAttributesSource
/GetAttributeDeclarations
? Basically make the definition part the source of truth for properties like BackingField
, UsesFieldKeyword
etc., digging into the implementation part symbol to obtain bits of information when the APIs are first accessed. #Resolved
@333fred, @RikkiGibson, @dotnet/roslyn-compiler, please review. |
// The property should only be used after members in the containing | ||
// type are complete, and partial members have been merged. | ||
return backingField; |
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 think we should also assert that we are in one of the scenarios which is known to have this problem (containing type has primary constructor). #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.
I don't think we can assert here since this is a property that might be invoked in the debugger, before containing members are complete.
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.
Could we assert !Debugger.IsAttached
?
See proposal.