dotnet · yowl · Jan 11, 2021 · Jan 11, 2021 · Jan 11, 2021 · Jan 12, 2021
diff --git a/.config/dotnet-tools.json b/.config/dotnet-tools.json
@@ -15,7 +15,7 @@
       ]
     },
     "microsoft.dotnet.xharness.cli": {
-      "version": "1.0.0-prerelease.20630.1",
+      "version": "1.0.0-prerelease.21068.3",
       "commands": [
         "xharness"
       ]

diff --git a/.editorconfig b/.editorconfig
@@ -196,5 +196,5 @@ indent_size = 2
 # Shell scripts
 [*.sh]
 end_of_line = lf
-[*.{cmd, bat}]
+[*.{cmd,bat}]
 end_of_line = crlf
diff --git a/Directory.Build.props b/Directory.Build.props
@@ -46,8 +46,6 @@
     <AspNetCoreAppCurrent>net$(AspNetCoreAppCurrentVersion)</AspNetCoreAppCurrent>
     <NetCoreAppToolCurrent>net$(NetCoreAppToolCurrentVersion)</NetCoreAppToolCurrent>
     <NetCoreAppCurrentToolTargetFrameworkMoniker>$(NetCoreAppCurrentIdentifier),Version=v$(NetCoreAppToolCurrentVersion)</NetCoreAppCurrentToolTargetFrameworkMoniker>
-    <!-- Used by Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk. -->
-    <NETCoreAppFramework>$(NetCoreAppCurrent)</NETCoreAppFramework>
     <SharedFrameworkName>Microsoft.NETCore.App</SharedFrameworkName>
     <NetCoreAppCurrentBrandName>.NET $(NetCoreAppCurrentVersion)</NetCoreAppCurrentBrandName>
   </PropertyGroup>
@@ -81,7 +79,7 @@
   </PropertyGroup>
 
   <PropertyGroup Label="CalculateConfiguration">
-    <!-- The RuntimeConfiguration property allows to pass in/specify a configuration that applies to both CoreCLR and Mono. --> 
+    <!-- The RuntimeConfiguration property allows to pass in/specify a configuration that applies to both CoreCLR and Mono. -->
     <RuntimeConfiguration Condition="'$(RuntimeConfiguration)' == ''">$(Configuration)</RuntimeConfiguration>
     <RuntimeConfiguration Condition="'$(RuntimeConfiguration)' == '' and ('$(Configuration)' == 'Debug' or '$(Configuration)' == 'Release')">$(Configuration)</RuntimeConfiguration>
     <RuntimeConfiguration Condition="'$(RuntimeConfiguration)' == ''">Debug</RuntimeConfiguration>
@@ -195,6 +193,10 @@
     <RestoreUseStaticGraphEvaluation>true</RestoreUseStaticGraphEvaluation>
     <!-- Turn off end of life target framework checks as we intentionally build older .NETCoreApp configurations. -->
     <CheckEolTargetFramework>false</CheckEolTargetFramework>
+    <!-- Disable source link when building locally. -->
+    <DisableSourceLink Condition="'$(DisableSourceLink)' == '' and
+                                  '$(ContinuousIntegrationBuild)' != 'true' and
+                                  '$(OfficialBuildId)' == ''">false</DisableSourceLink>
   </PropertyGroup>
 
   <!-- RepositoryEngineeringDir isn't set when Installer tests import this file. -->
@@ -239,7 +241,7 @@
                                   '$(RepositoryName)' == 'runtimelab') and
                                  '$(BuildAllProjects)' == 'true')">false</GeneratePackage>
   </PropertyGroup>
-  
+
 
   <!-- Language configuration -->
   <PropertyGroup>

diff --git a/THIRD-PARTY-NOTICES.TXT b/THIRD-PARTY-NOTICES.TXT
@@ -15,9 +15,9 @@ Copyright (c) .NET Foundation. All rights reserved.
 Licensed under the Apache License, Version 2.0.
 
 Available at
-https://github.com/aspnet/AspNetCore/blob/master/LICENSE.txt
+https://github.com/dotnet/aspnetcore/blob/master/LICENSE.txt
 
-License notice for Slicing-by-8 
+License notice for Slicing-by-8
 -------------------------------
 
 http://sourceforge.net/projects/slicing-by-8/
@@ -66,7 +66,7 @@ shall not be used in advertising or otherwise to promote the sale,
 use or other dealings in these Data Files or Software without prior
 written authorization of the copyright holder.
 
-License notice for Zlib 
+License notice for Zlib
 -----------------------
 
 https://github.com/madler/zlib
@@ -117,12 +117,12 @@ furnished to do so,  subject to the following conditions:
 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.
 
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
-MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
-NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE 
-LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION 
-OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION 
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
 WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
 License notice for International Organization for Standardization
@@ -232,7 +232,7 @@ noted) — feel free to use them however you please. The aggregate collection an
 descriptions are © 1997-2005 Sean Eron Anderson. The code and descriptions are
 distributed in the hope that they will be useful, but WITHOUT ANY WARRANTY and
 without even the implied warranty of merchantability or fitness for a particular
-purpose. 
+purpose.
 
 License notice for Brotli
 --------------------------------------
@@ -378,7 +378,7 @@ License notice for RFC 3492
 ---------------------------
 
 The punycode implementation is based on the sample code in RFC 3492
-        
+
 Copyright (C) The Internet Society (2003).  All Rights Reserved.
 
 This document and translations of it may be copied and furnished to
@@ -448,7 +448,7 @@ ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
 PARTICULAR PURPOSE.
 
-License notice for Algorithm from RFC 4122 - 
+License notice for Algorithm from RFC 4122 -
 A Universally Unique IDentifier (UUID) URN Namespace
 ----------------------------------------------------
 
@@ -517,8 +517,8 @@ License notice for Greg Parker
 ------------------------------
 
 Greg Parker     gparker@cs.stanford.edu     December 2000
-This code is in the public domain and may be copied or modified without 
-permission. 
+This code is in the public domain and may be copied or modified without
+permission.
 
 License notice for libunwind based code
 ----------------------------------------
@@ -548,23 +548,23 @@ License notice for Printing Floating-Point Numbers (Dragon4)
 /******************************************************************************
   Copyright (c) 2014 Ryan Juckett
   http://www.ryanjuckett.com/
- 
+
   This software is provided 'as-is', without any express or implied
   warranty. In no event will the authors be held liable for any damages
   arising from the use of this software.
- 
+
   Permission is granted to anyone to use this software for any purpose,
   including commercial applications, and to alter it and redistribute it
   freely, subject to the following restrictions:
- 
+
   1. The origin of this software must not be misrepresented; you must not
      claim that you wrote the original software. If you use this software
      in a product, an acknowledgment in the product documentation would be
      appreciated but is not required.
- 
+
   2. Altered source versions must be plainly marked as such, and must not be
      misrepresented as being the original software.
- 
+
   3. This notice may not be removed or altered from any source
      distribution.
 ******************************************************************************/

diff --git a/docs/area-owners.md b/docs/area-owners.md
@@ -75,7 +75,7 @@ Note: Editing this file doesn't update the mapping used by the `@msftbot` issue
 | area-System.Diagnostics                        | @tommcdon     | @tommcdon @krwq                                     | <ul><li>System.Diagnostics.EventLog - [@Anipik](https://github.com/Anipik)</li></ul>                                                                                                                                                                                                      |
 | area-System.Diagnostics.Process                | @jeffhandley  | @adamsitnik @eiriktsarpalis                         |                                                                                                                                                                                                                                                                                           |
 | area-System.Diagnostics.Tracing                | @tommcdon     | @noahfalk @tommcdon @tarekgh @Anipik                | Packages:<ul><li>System.Diagnostics.DiagnosticSource</li><li>System.Diagnostics.PerformanceCounter - [@Anipik](https://github.com/Anipik)</li><li>System.Diagnostics.Tracing</li><li>System.Diagnostics.TraceSource - [@Anipik](https://github.com/Anipik)</li></ul><br/>                 |
-| area-System.DirectoryServices                  | @tquerec      | @tquerec @josephisenhour @joperezr                  |                                                                                                                                                                                                                                                                                           |
+| area-System.DirectoryServices                  | @ericstj      | @tquerec @josephisenhour @joperezr                  |                                                                                                                                                                                                                                                                                           |
 | area-System.Drawing                            | @jeffhandley  | @safern @tannergooding                              |                                                                                                                                                                                                                                                                                           |
 | area-System.Dynamic.Runtime                    | @jaredpar     | @cston @333fred                                     | Archived component - limited churn/contributions (see [#27790](https://github.com/dotnet/runtime/issues/27790))                                                                                                                                                                           |
 | area-System.Formats.Asn1                       | @jeffhandley  | @bartonjs @eiriktsarpalis @GrabYourPitchforks       |                                                                                                                                                                                                                                                                                           |

diff --git a/docs/coding-guidelines/api-guidelines/nullability.md b/docs/coding-guidelines/api-guidelines/nullability.md
@@ -67,7 +67,7 @@ However, for existing virtual APIs that do not have any such strong guarantee do
 4. How common is it in the case of (3) for such invocations to then dereference the result rather than passing it off to something else that accepts a `T?`?
 
 `Object.ToString` is arguably the most extreme case.  Answering the above questions:
-1. It is fairly easy in any reasonably-sized code base to find cases, intentional or otherwise, where `ToString` returns `null` in some cases (we've found examples in dotnet/corefx, dotnet/roslyn, NuGet/NuGet.Client, aspnet/AspNetCore, and so on).  One of the most prevalent conditions for this are types that just return the value in a string field which may contain its default value of `null`, and in particular for structs where a ctor may not have even had a chance to run and validate an input.  Guidance in the docs suggests that `ToString` shouldn't return `null` or `string.Empty`, but even the docs don't follow its own guidance.
+1. It is fairly easy in any reasonably-sized code base to find cases, intentional or otherwise, where `ToString` returns `null` in some cases (we've found examples in dotnet/corefx, dotnet/roslyn, NuGet/NuGet.Client, dotnet/aspnetcore, and so on).  One of the most prevalent conditions for this are types that just return the value in a string field which may contain its default value of `null`, and in particular for structs where a ctor may not have even had a chance to run and validate an input.  Guidance in the docs suggests that `ToString` shouldn't return `null` or `string.Empty`, but even the docs don't follow its own guidance.
 2. Thousands upon thousands of types we don't control override this method today.
 3. It's common for helper routines to invoke via the base `object.ToString`, but many `ToString` uses are actually on derived types.  This is particularly true when working in a code base that both defines a type and consumes its `ToString`.
 4. Based on examination of several large code bases, we believe it to be relatively rare that the result of an `Object.ToString` call (made on the base) to be directly dereferenced.  It's much more common to pass it to another method that accepts `string?`, such as `String.Concat`, `String.Format`, `Console.WriteLine`, logging utilities, and so on.  And while we advocate that `ToString` results shouldn't be assumed to be in a particular machine-readable format and parsed, it's certainly the case that code bases do, such as using `Substring` on the result, but in such cases, the caller needs to understand the format of what's being rendered, which generally means they're working with a derived type rather than calling through the base `Object.ToString`.

diff --git a/docs/design/features/source-generator-pinvokes.md b/docs/design/features/source-generator-pinvokes.md
@@ -117,7 +117,7 @@ In this system it is not defined how marshaling of specific types would be perfo
 
 In the current Source Generator design modification of any user written code is not permitted. This includes modification of any non-functional metadata (e.g. Attributes). The above design therefore introduces a new attribute and signature for consumption of a native export. In order to consume Source Generators, users would need to update their source and adoption could be stunted by this requirement.
 
-As a mitigation it would be possible to create a [Roslyn Analyzer and Code fix](https://github.com/dotnet/roslyn/wiki/Getting-Started-Writing-a-Custom-Analyzer-&-Code-Fix) to aid the developer in converting `DllImportAttribute` marked functions to use `GeneratedDllImportAttribute`. Additionally, the function signature would need to be updated to remove the `extern` keyword and add the `partial` keyword to the function and potentially the enclosing class.
+As a mitigation it would be possible to create a [Roslyn Analyzer and Code fix](https://github.com/dotnet/roslyn/blob/master/docs/wiki/Getting-Started-Writing-a-Custom-Analyzer-&-Code-Fix.md) to aid the developer in converting `DllImportAttribute` marked functions to use `GeneratedDllImportAttribute`. Additionally, the function signature would need to be updated to remove the `extern` keyword and add the `partial` keyword to the function and potentially the enclosing class.
 
 ## Proposed API
 

diff --git a/docs/issues-pr-management.md b/docs/issues-pr-management.md
@@ -4,8 +4,8 @@ The purpose of this document is to help establish norms and best practices for d
 Here are a guiding set of principles of how to successfully combine the communities and teams which work together in dotnet/runtime.
 - Retain a 'one community/team' feel for dotnet/runtime
 - Leverage automation to label incoming/inflight to enable accountability
-- area-* labels should align with a specific community/team for accountability
-- Within an area-* there is leeway for community/team specific practices
+- `area-*` labels should align with a specific community/team for accountability
+- Within an `area-*` there is leeway for community/team specific practices
 # Details
 dotnet/runtime issues and pull requests are a shared resource. In alignment with the Principles the goal is to find a set of norms and best practices which enable a successful community within dotnet/runtime, understand what is expected, act as 'one community/team', and provide leeway at the area level.
 

diff --git a/docs/project/profiling-api-status.md b/docs/project/profiling-api-status.md
@@ -1,27 +1,20 @@
 # Status of CoreCLR Profiler APIs
 
-The CoreCLR project started with the codebase from the .NET Framework so all the profiler APIs present there are also present in the code here. This is the status of our testing and porting efforts for these APIs.
+Below is a table of the version of CoreCLR that profiler support and testing was completed. Profiling may work prior to these versions, but there may be bugs and missing features.
 
-## Platform test coverage
-
-- Windows on x86/x64/arm32
-- Linux on x86/x64/arm32
-- OSX
+|       | Windows | Linux | OSX |
+| ----- | ------- | ----- | --- |
+| x64   | 2.1     | 2.1   | 3.1 |
+| x86   | 2.1     | N/A   | N/A |
+| arm32 | 3.1     | 3.1   | N/A |
+| arm64 | 3.1     | 3.1   | TBA |
 
 ## Known issues
 
 ### DoStackSnapshot
 
 The implementation of this API was making some questionable assumptions about Windows OS API behavior in order to walk callstacks asynchronously. When operating in this async mode we aren't yet confident we can produce reasonable implementations for other platforms. Our understanding is that most users of this API are attempting to do sample based profiling. If so we think it may be easier to offer a runtime provided event stream of sample callstacks to accomplish the same scenario without needing the API, but we also haven't heard any demand for it. Feedback welcome!
 
-### ReJIT on ARM
-
-ReJIT feature is only available on x86/x64 for now.
-
-### Profiler Attach/Detach
-
-We only support launch at the moment, see https://github.com/dotnet/runtime/issues/9886
-
 ### Any issues we missed?
 
 Please let us know and we will get it addressed. Thanks!