[Strict] Do not ignore private reference fields of structs for definite assignment

[gafter]

In Dev12 the C# compiler ignored private fields of reference type in a value type imported from metadata when computing definite assignment. Roslyn duplicates that bug for compatibility. In "strict" mode we do not duplicate that bug.

Consider enabling this bug to be fixed in the first warning wave.

[gafter]

Here is a first draft of a proposal for this (to address dotnet/csharplang#3431)

There are two ways of doing data flow analysis. The strong version includes tracking inaccessible fields of structs. The weak version ignores inaccessible fields. (The precise rule is a bit more subtle. I believe we only ignore fields of reference type in the weak version). The compiler currently runs the weak version except in “strict” mode, in which case we run the strong version.

We propose to make the following changes in the C# 9 (dotnet 5) timeframe.

1. If a method has the [SkipLocalsInit] attribute, or the compilation has the "strict" feature enabled, we use the strong version of analysis for its body. Otherwise
2. If a sufficiently high /warnversion (>= 5) is enabled, we run the strong version of analysis, and
   1. If it reports no diagnostics, we are done.
   2. If it reports diagnostics, we run the weak version of analysis. Errors that are common to the two runs are reported as errors, and errors only reported by the strong version are downgraded to a warning.
3. Otherwise we run the weak version of analysis.

[gafter]

A simpler alternative proposal would be

If any of the following conditions are true, we run the strong version of analysis

• the method has the [SkipLocalsInit] attribute
• the compilation has the "strict" feature enabled
• a sufficiently high /warnversion (>= 5) is enabled

otherwise we run the weak version of analysis.

[gafter]

We settled on the first approach. However, we will not treat [SkipLocalsInit], "strict" mode, or warning waves differently. We will always use the two-pass approach when there are errors, and the downgraded warning will have a warning level of 5. In other words:

• we (always) run the strong version of analysis, and If it reports no diagnostics, we are done. Otherwise
• We run the weak version of analysis.
  • Errors that are common to the two runs are reported as errors
  • Errors only reported by the strong version are downgraded to a warning.