Skip to content

Commit

Permalink
Merge pull request dotnet#13 from joperezr/runtime-ingestion
Browse files Browse the repository at this point in the history
Runtime ingestion
  • Loading branch information
joperezr committed Jul 15, 2020
2 parents af7beb0 + d5adb68 commit b83a26c
Show file tree
Hide file tree
Showing 2,666 changed files with 155,898 additions and 32,307 deletions.
2 changes: 1 addition & 1 deletion .config/dotnet-tools.json
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@
]
},
"microsoft.dotnet.xharness.cli": {
"version": "1.0.0-prerelease.20303.2",
"version": "1.0.0-prerelease.20329.4",
"commands": [
"xharness"
]
Expand Down
10 changes: 6 additions & 4 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
6 changes: 6 additions & 0 deletions Directory.Solution.props
Original file line number Diff line number Diff line change
@@ -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>
1 change: 0 additions & 1 deletion docs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
=================
Expand Down
28 changes: 14 additions & 14 deletions docs/area-owners.md

Large diffs are not rendered by default.

3 changes: 2 additions & 1 deletion docs/coding-guidelines/api-guidelines/nullability.md
Original file line number Diff line number Diff line change
Expand Up @@ -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`.
Expand Down Expand Up @@ -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

Expand Down
Loading

0 comments on commit b83a26c

Please sign in to comment.