Add private fields for structs#1012
Conversation
|
Do you have tooling to generate these files? GenAPI should do the right thing now and I trust that more than my eyes to review the sources (though I do trust @jkotas's 😄 ) |
You mean the reference assembly? I've used API Reviewer to export the .NET Core 3.0 reference assemblies into a one-file-per-namespace and that's what I diff against .NET Standard using Beyond Compare. So the private field information is taken from the .NET Core. |
|
I see, so you're relying on us getting it right in the .NETCore references. I was chatting with @ahsonkhan the other day that we were missing an APICompat rule to keep those _private fields up to date. As a result we'll probably want to do another pass on this before shipping. I've opened dotnet/arcade#1560 to track fixing API Compat. |
703946b to
cb7db61
Compare
Sounds good to me. Was just thinking about how we enforce that a given struct conforms to the characteristic and I was doubting that APICompat did this already. Glad to hear it will be taken care of. @ericstj, any reason we shouldn't merge this iteration as a down payment? |
This fixes dotnet#678. In a nutshell, the compiler needs to know whether a struct has any fields in order to apply definitive assignment rules. While stripping all private fields from types is generally OK, we can't do this for structs. Fortunately, for private fields the compiler doesn't really care what they are, but what their characteristics are. For example: 1. Does the struct have any fields? 2. Does the struct contain any reference types (to validate generic instantiations that have the unmanaged constraint)? 3. Does the struct use the generic parameter in a field declaration (to validate cyclic layout problems)? This adds dummy fields to structs to conform to these rules. These aren't computed separately but are instead taken from .NET Core. For more details, see this issue in CoreFX: https://github.com/dotnet/corefx/issues/6185
cb7db61 to
ced9376
Compare
|
So long as you can repeat it reasonably well in the future I'm fine with that. |
|
Such a _dummy change 😉 |
|
OK, given that this isn't publicly facing I'm not going to wait for @dotnet/nsboard-unity and @dotnet/nsboard-xamarin. If you have concerns, let me know :-) |
|
@terrajobst I'm having trouble finding the netstandard 2.0 release that contains these fields. The lack of the fields is causing the Make Field Readonly refactoring in Visual Studio to silently break code in Roslyn. |
|
We didn't do it in time for .NET Standard 2.0. This change is only in 2.1. |
No public API changes, but this fixes #678.
In a nutshell, the compiler needs to know whether a struct has any fields in order to apply definitive assignment rules. While stripping all private fields from types is generally OK, we can't do this for structs. Fortunately, for private fields the compiler doesn't really care what they are, but what their characteristics are. For example:
Does the struct have any fields?
Does the struct contain any reference types (to validate generic instantiations that have the unmanaged constraint)?
Does the struct use the generic parameter in a field declaration (to validate cyclic layout problems)?
This adds dummy fields to structs to conform to these rules. These aren't computed separately but are instead taken from .NET Core.
For more details, see this issue in CoreFX:
https://github.com/dotnet/corefx/issues/6185