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
Treat record structs as records #2009
Merged
Merged
Changes from 5 commits
Commits
Show all changes
16 commits
Select commit
Hold shift + click to select a range
6a55818
Treat record structs as records (issue #1808)
2045c6a
Use BeFalse in IsRecord assertions
2ac999a
Merge remote-tracking branch 'upstream/develop' into develop
df8558b
Update releases.md and reformat TypeExtensions.IsRecord.
3ca8329
Improve documentation about record structs
e94230b
No need to be explicit about readonly record structs
dd70875
Merge upstream/develop into #2009
b8e8cc3
Merge upstream/develop into #2009
105b5ca
Simplify expression to guess whether a type is a record struct.
4929350
Add test case for record struct with custom PrintMembers.
68869a7
Add test case for value tuples not being mistaken for a record struct.
916df63
Add a test case for a false positive in record struct detection.
12d404e
Merge remote-tracking branch 'upstream/develop' into develop
cbb3cd5
Check for record struct also looks for PrintMembers per @jnyrup sugge…
f8d0b39
Update docs/_pages/objectgraphs.md
jnyrup 3be69bb
Update docs/_pages/objectgraphs.md
jnyrup File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -39,7 +39,7 @@ orderDto.Should().BeEquivalentTo(order, options => | |||||
|
||||||
### Value Types | ||||||
|
||||||
To determine whether Fluent Assertions should recurs into an object's properties or fields, it needs to understand what types have value semantics and what types should be treated as reference types. The default behavior is to treat every type that overrides `Object.Equals` as an object that was designed to have value semantics. Anonymous types, records and tuples also override this method, but because the community proved us that they use them quite often in equivalency comparisons, we decided to always compare them by their members. | ||||||
To determine whether Fluent Assertions should recurs into an object's properties or fields, it needs to understand what types have value semantics and what types should be treated as reference types. The default behavior is to treat every type that overrides `Object.Equals` as an object that was designed to have value semantics. Anonymous types, records, record structs, readonly record structs and tuples also override this method, but because the community proved us that they use them quite often in equivalency comparisons, we decided to always compare them by their members. | ||||||
jnyrup marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
||||||
You can easily override this by using the `ComparingByValue<T>`, `ComparingByMembers<T>`, `ComparingRecordsByValue` and `ComparingRecordsByMembers` options for individual assertions: | ||||||
|
||||||
|
@@ -48,7 +48,7 @@ subject.Should().BeEquivalentTo(expected, | |||||
options => options.ComparingByValue<IPAddress>()); | ||||||
``` | ||||||
|
||||||
For records, this works like this: | ||||||
For records, record structs and readonly record structs this works like this: | ||||||
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.
Suggested change
|
||||||
|
||||||
```csharp | ||||||
actual.Should().BeEquivalentTo(expected, options => options | ||||||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
While this is probably the best we can currently do, I wonder a bit if this is still too broad a check?
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'm afraid of this too. This is backed by MSDN too (see comment). I've tried my best to "crack" this test and was not able to, but please feel free to add counter-examples.
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.
Checking for one operator should be enough.
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 had another look at creating a heuristic to identify record structs with few false positives.
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-10.0/record-structs#printing-members-printmembers-and-tostring-methods
specifies that a
record struct
contains a synthesized (read has[CompilerGenerated]
)The name
PrintMembers
is also a public part of Roslyn.What do you think about this?
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.
That may be a good catch. I'll look into it!
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.
Not sure I understand you here 🤔
As a record struct currently doesn't have any unspeakable parts, it's always possible to write a struct in plain C# that looks like a record struct.
E.g. this is valid C# code, SharpLab
I tried another thing.
I made a
record struct Auto {}
and copied its output back into regular C# code.The only thing I wasn't allowed to was using
[IsReadOnly]
as that gave a compiler error.PrintMembers
is annotated with[IsReadOnly]
So what do you think about checking for this?
I don't know if an arbitrary source generator is allowed to use
[IsReadOnly]
.IL weaving would most likely be able to circumvent CS8335, but we aren't looking for a bullet proof solution.
SharpLab
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.
Interesting! I didn't know one could annotate with [CompilerGenerated] in source code; it looks a little silly to me that you can, but it is what it is I suppose :)
In this case, I definitely like your proposal with PrintMembers and IsReadOnly more. Let me try to give a couple of final touches and I'll be back with a new commit.
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.
@jnyrup I have just tried the last proposal checking for a PrintMembers annotated with IsReadOnly. IsReadOnly is not available on NET47 and NETSTANDARD2_0, so it does not compile on those target, but here the problem is just my ignorance on properly handling multi-target.
The major problem for me is that the check fails for the MyReadOnlyRecordStruct and MyRecordStructWithCustomPrintMembers tests, for which PrintMembers has not the IsReadOnly attribute.
For this reason, at the end of the day (literally, for me 😄 ) I believe the lesser evil for now is checking for compiler generated equality, knowing that we can have a false positive if someone uses the [CompilerGenerated] attribute in source code (I have added a test to document this).
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.
Aha!
I hadn't thought about the case in
MyRecordStructWithCustomPrintMembers
where one implementsPrintMembers
themselves such that the compiler doesn't create one.Well found 👍
So it seems there will always be a
PrintMembers
, but we don't know who wrote it.This code handles all your test cases and the false positive.
I would be confident enough with this one.
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.
Good idea: this way we rely on the two documented behaviors of record structs!
There is still a small possibility of a false positive, where one both implements a PrintMember and annotates equality with [CompilerGenerated] (I have added a test for reference), but I'd consider such code as deliberate sabotage 😄