You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Public struct with only private or internal fields may need to emit a substitute private field. Otherwise S s; M(s); will not complain about s being un-initialized.
For the record, one issue with refout is that if you have InternalsVisibleTo in your program we will include more types and more dependencies into the ref assembly. This was raised by Eric StJohn.
The text was updated successfully, but these errors were encountered:
@jcouv I cannot find an issue describing the long-term behavior of fields of structs. Analysis in #19067 and other analyzers aimed at detecting misuse of mutable value types requires that reference assemblies contain private fields. I'm planning to proceed as though these fields will continue to not be stripped, as changes to this behavior would cause substantial downstream limitations.
@sharwell If a struct only contains private fields, it is safe to assume that in a ref assembly it will always contain at least one private field (but maybe not all).
If you b think stripping any private field is a problem, let me know.
This is a list of possible future improvements (following dev15.3 refout work).
We should generate a ref assembly even if there are errors on types (emit some form of error types instead) Produce skeleton assemblies tolerating errors #20914
Get telemetry in place to measure impact of this optimization
Provide a code action to help upgrade projects to deterministic and refout
Make the ref assemblies produced by refout and refonly match (as closely as possible) Ref assemblies produced by refout have more types than that produced by refonly #19403
Public struct with only private or internal fields may need to emit a substitute private field. Otherwise
S s; M(s);
will not complain abouts
being un-initialized.Consider more errors to be semantic errors as opposed to syntax errors, especially within method bodies Feature request: Allow an output assembly to be generated even if there are errors in the source #21560
Integrate into various other build systems
For the record, one issue with
refout
is that if you haveInternalsVisibleTo
in your program we will include more types and more dependencies into the ref assembly. This was raised by Eric StJohn.The text was updated successfully, but these errors were encountered: