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
Merge common code bases for TdsParserStateObject.cs (3) #2168
Conversation
Codecov ReportAttention:
... and 7 files with indirect coverage changes 📢 Thoughts on this report? Let us know!. |
13aa573
to
9b98c8e
Compare
I just rebased the branch adding a few commits, in order to follow @David-Engel's suggestion:
|
That's still a lot of changes to review with the care we need. I've gone through them all and made notes so I'll put my notes here to help others, function by function. TryPeekByte - identical in both It would be good to understand what the reliability assert is supposed to be doing and see if there a way we can make it compile out completely on netcore. |
Good to see you reviewing this @Wraith2, since you wrote #667 and #285. If it helps:
|
My personal preference would be to use Interlocked.MemoryBarrier everywhere if possible. It fits more closely with the logical intention than using the Thread version to me. Either version would work identically so it's not a huge issue. For spans since they're structs comparing against null has never made sense to me and I'd prefer to have IsEmpty used everywhere if possible. It was probably me that got it wrong but since you're here you can correct it :) As long as codegen confirms that the reliability call is entirely compiled out i'm fine with it as you've ported it. |
I agree, that's why I chose Interlocked.MemoryBarrier.
Comparing against null is a indeed confusing, because of the implicit conversion. You can use Span.Empty instead. However it isn't exactly the same as checking IsEmpty in case of an empty array. In which case, the null-check triggers Debug.Assert while IsEmpty doesn't. But in the end of the day I think it doesn't really matter, since it is just a debug assertion and the code below it handles both null and empty arrays the same way.
I think we could add Debug.Assert or throw an exception inside the stub, to verify it is omitted without having to look at the codegen. An exception would also make tests fail. What do you think? |
9b98c8e
to
98f818a
Compare
@David-Engel My bad, you are right. I will force-push the previously reviewed commits and add a merge commit on top. |
# Conflicts: # src/Microsoft.Data.SqlClient/netcore/src/Microsoft/Data/SqlClient/TdsParserStateObject.netcore.cs # src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/TdsParserStateObject.cs
98f818a
to
ca8eebd
Compare
Basically the first two commits of #1844. Plus an optional refactoring. Let me know what you think.