Runtime ingestion

.config/dotnet-tools.json

@@ -15,7 +15,7 @@
       ]
     },
     "microsoft.dotnet.xharness.cli": {
-      "version": "1.0.0-prerelease.20303.2",
+      "version": "1.0.0-prerelease.20329.4",
       "commands": [
         "xharness"
       ]

.gitignore

@@ -3,10 +3,12 @@ syntax: glob
 ### VisualStudio ###
 
 # Tool Runtime Dir
-.dotnet/
-.dotnet-mono/
-.packages/
-.tools/
+# note: there is no trailing slash so if these are symlinks (which are seen as files,
+#       instead of directories), git will still ignore them.
+.dotnet
+.dotnet-mono
+.packages
+.tools
 
 # User-specific files
 *.suo

Directory.Solution.props

@@ -0,0 +1,6 @@
+<Project>
+  <PropertyGroup>
+    <!-- For solution restore, msbuild doesn't honor the property set in Directory.Build.props. -->
+    <RestoreUseStaticGraphEvaluation>true</RestoreUseStaticGraphEvaluation>
+  </PropertyGroup>
+</Project>

docs/README.md

@@ -58,7 +58,6 @@ Coding Guidelines
 - [Breaking Change Rules](coding-guidelines/breaking-change-rules.md)
 - [Project Guidelines](coding-guidelines/project-guidelines.md)
 - [Adding APIs Guidelines](coding-guidelines/adding-api-guidelines.md)
-- [Legal Native calls](coding-guidelines/pinvoke-checker.md)
 
 Project Docs
 =================

docs/coding-guidelines/api-guidelines/nullability.md

@@ -35,6 +35,7 @@ The majority of reference type usage in our APIs is fairly clear as to whether i
 - **DO** define a parameter as nullable if the parameter is explicitly documented to accept `null`.
 - **DO** define a parameter as nullable if the method checks the parameter for `null` and does something other than throw.  This may include normalizing the input, e.g. treating `null` as `string.Empty`.
 - **DO** define a parameter as nullable if the parameter is optional and has a default value of `null`.
+- **DO** define `string message` and `Exception innerException` arguments to `Exception`-derived types as nullable.  Additional reference type arguments to `Exception`-derived types should, in general, also be nullable unless not doing so is required for compatibility.
 - **DO** prefer nullable over non-nullable if there's any disagreement between the previous guidelines.  For example, if a non-virtual method has documentation that suggests `null` isn't accepted but the implementation explicitly checks for, normalizes, and accepts a `null` input, the parameter should be defined nullable.
 
 However, there are some gray areas that require case-by-case analysis to determine intent. In particular, if a parameter isn't validated nor sanitized nor documented regarding `null`, but in some cases simply ignored such that a `null` doesn't currently cause any problems, several factors should be considered when determining whether to annotate it as `null`.
@@ -97,7 +98,7 @@ The C# compiler respects a set of attributes that impact its flow analysis.  We
 - **DO** add `[NotNullWhen(true)]` to nullable arguments of `Try` methods that will definitively be non-`null` if the method returns `true`.  For example, if `Int32.TryParse(string? s)` returns `true`, `s` is known to not be `null`, and so the method should be `public static bool TryParse([NotNullWhen(true)] string? s, out int result)`.
 - **DO** add `[NotNullIfNotNull(string)]` if nullable ref argument will be non-`null` upon exit, when an other argument passed evaluated to non-`null`, pass that argument name as string. Example: `public void Exchange([NotNullIfNotNull("value")] ref object? location, object? value);`.
 - **DO** add `[return: NotNullIfNotNull(string)]` if a method would not return `null` in case an argument passed evaluated to non-`null`, pass that argument name as string. Example: `[return: NotNullIfNotNull("name")] public string? FormatName(string? name);`
-- **DO** add `[MemberNotNull(params string[])]` for a helper method which initializes member field(s), pass the field name. Example: `[MemberNotNull("_buffer")] private void InitializeBuffer()`
+- **DO** add `[MemberNotNull(string fieldName)]` to a helper method which initializes member field(s), passing in the field name. Example: `[MemberNotNull("_buffer")] private void InitializeBuffer()`.  This will help to avoid spurious warnings at call sites that call the initialization method and then proceed to use the specified field.  Note that there are two constructors to `MemberNotNull`; one that takes a single `string`, and one that takes a `params string[]`.  When the number of fields initialized is small (e.g. <= 3), it's preferable to use multiple `[MemberNotNull(string)]` attributes on the method rather than one `[MemberNotNull(string, string, string, ...)]` attribute, as the latter is not CLS compliant and will likely require `#pragma warning disable` and `#pragma warning restore` around the line to suppress warnings.
 
 ## Code Review Guidance