Imported Upstream version 5.4.0.167

Former-commit-id: 5624ac747d633e885131e8349322922b6a59baaa

external/corefx/Documentation/coding-guidelines/breaking-change-rules.md

@@ -155,9 +155,6 @@ Breaking Change Rules
 
 * Changing a member from `abstract` to `virtual`
 
-* Adding `virtual` to a member  
-> Make note, that marking a member virtual might cause previous consumers to still call the member non-virtually.
-
 * Introducing or removing an override
 > Make note, that introducing an override might cause previous consumers to skip over the override when calling `base`.
 
@@ -180,6 +177,9 @@ successfully bind to that overload, if simply passing an `int` value. However, i
 
 * Removing the `virtual` keyword from a member
 
+* Adding `virtual` to a member
+> While this change would often work without breaking too many scenarios because C# compiler tends to emit `callvirt` IL instructions to call non-virtual methods (`callvirt` performs a null check, while a normal `call` won't), we can't rely on it. C# is not the only language we target and the C# compiler increasingly tries to optimize `callvirt` to a normal `call` whenever the target method is non-virtual and the `this` is provably not null (such as a method accessed through the `?.` null propagation operator). Making a method virtual would mean that consumer code would often end up calling it non-virtually.
+
 * Adding or removing `static` keyword from a member
 
 ### Signatures

external/corefx/Documentation/coding-guidelines/project-guidelines.md

@@ -251,5 +251,5 @@ Each source file should use the following guidelines
 ## Define naming convention
 As mentioned in [Conventions for forked code](conventions-for-forked-code) `#ifdef`ing the code is the last resort as it makes code harder to maintain overtime. If we do need to use `#ifdef`'s we should use the following conventions:
 - Defines based on conventions should be one of `$(OSGroup)`, `$(TargetGroup)`, `$(ConfigurationGroup)`, or `$(Platform)`, matching exactly by case to ensure consistency.
- - Examples: `<DefineConstants>$(DefineConstants),net46</DefineContants>`
+ - Examples: `<DefineConstants>$(DefineConstants);net46</DefineConstants>`
 - Defines based on convention should match the pattern `FEATURE_<feature name>`. These can unique to a given library project or potentially shared (via name) across multiple projects.