Merge remote-tracking branch 'dotnet/main' into cleanup/lsra-remerge

.config/dotnet-tools.json

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

CONTRIBUTING.md

@@ -61,20 +61,21 @@ The best way to create a minimal reproduction is gradually removing code and dep
 
 Project maintainers will merge changes that improve the product significantly and broadly align with the [.NET Roadmap](https://github.com/dotnet/core/blob/master/roadmap.md).
 
-Maintainers will not merge changes that have narrowly-defined benefits, due to compatibility risk. The .NET Core codebase is used by several Microsoft products (for example, ASP.NET Core, .NET Framework 4.x, Windows Universal Apps) to enable execution of managed code. Other companies are building products on top of .NET, too. We may revert changes if they are found to be breaking.
+Maintainers will not merge changes that have narrowly-defined benefits, due to compatibility risk. .NET is used by several Microsoft products (for example, ASP.NET Core, .NET Framework 4.x, Windows Universal Apps) to enable execution of managed code. Other companies are building products on top of .NET, too. We may revert changes if they are found to be breaking.
 
 Contributions must also satisfy the other published guidelines defined in this document as well as in [pr-guide docs](docs/pr-guide.md).
 
 ### DOs and DON'Ts
 
 Please do:
 
-* **DO** follow our [coding style](docs/coding-guidelines/coding-style.md) (C# code-specific)
+* **DO** follow our [coding style](docs/coding-guidelines/coding-style.md) (C# code-specific).
 * **DO** give priority to the current style of the project or file you're changing even if it diverges from the general guidelines.
 * **DO** include tests when adding new features. When fixing bugs, start with
   adding a test that highlights how the current behavior is broken.
 * **DO** keep the discussions focused. When a new or related topic comes up
   it's often better to create new issue than to side track the discussion.
+* **DO** clearly state on an issue that you are going to take on implementing it.
 * **DO** blog and tweet (or whatever) about your contributions, frequently!
 
 Please do not:
@@ -83,7 +84,7 @@ Please do not:
 * **DON'T** surprise us with big pull requests. Instead, file an issue and start
   a discussion so we can agree on a direction before you invest a large amount
   of time.
-* **DON'T** commit code that you didn't write. If you find code that you think is a good fit to add to .NET Core, file an issue and start a discussion before proceeding.
+* **DON'T** commit code that you didn't write. If you find code that you think is a good fit to add to the .NET runtime, file an issue and start a discussion before proceeding.
 * **DON'T** submit PRs that alter licensing related files or headers. If you believe there's a problem with them, file an issue and we'll be happy to discuss it.
 * **DON'T** add API additions without filing an issue and discussing with us first. See [API Review Process](docs/project/api-review-process.md).
 
@@ -154,7 +155,7 @@ You don't have to do this up-front. You can simply clone, fork, and submit your
 
 ### File Headers
 
-The following file header is the used for .NET Core. Please use it for new files.
+The following file header is the used for files in this repo. Please use it for new files.
 
 ```
 // Licensed to the .NET Foundation under one or more agreements.
@@ -201,7 +202,7 @@ Ports have a weaker contribution bar, at least initially. A functionally correct
 
 #### Copying Files from Other Projects
 
-.NET Core uses some files from other projects, typically where a binary distribution does not exist or would be inconvenient.
+The .NET runtime uses some files from other projects, typically where a binary distribution does not exist or would be inconvenient.
 
 The following rules must be followed for PRs that include files from another project:
 
@@ -213,6 +214,6 @@ See [IdnMapping.cs](./src/libraries/System.Private.CoreLib/src/System/Globalizat
 
 #### Porting Files from Other Projects
 
-There are many good algorithms implemented in other languages that would benefit the .NET Core project. The rules for porting a Java file to C#, for example, are the same as would be used for copying the same file, as described above.
+There are many good algorithms implemented in other languages that would benefit the .NET runtime. The rules for porting a Java file to C#, for example, are the same as would be used for copying the same file, as described above.
 
 [Clean-room](https://en.wikipedia.org/wiki/Clean_room_design) implementations of existing algorithms that are not permissively licensed will generally not be accepted. If you want to create or nominate such an implementation, please create an issue to discuss the idea.

docs/project/list-of-diagnostics.md

@@ -102,6 +102,7 @@ The PR that reveals the implementation of the `<IncludeInternalObsoleteAttribute
 |  __`SYSLIB0045`__ | Cryptographic factory methods accepting an algorithm name are obsolete. Use the parameterless Create factory method on the algorithm type instead. |
 |  __`SYSLIB0046`__ | ControlledExecution.Run method may corrupt the process and should not be used in production code. |
 |  __`SYSLIB0047`__ | XmlSecureResolver is obsolete. Use XmlResolver.ThrowingResolver instead when attempting to forbid XML external entity resolution. |
+|  __`SYSLIB0048`__ | RSA.EncryptValue and DecryptValue are not supported and throw NotSupportedException. Use RSA.Encrypt and RSA.Decrypt instead. |
 
 ## Analyzer Warnings
 

docs/workflow/building/coreclr/linux-instructions.md

@@ -45,7 +45,7 @@ Note that instructions on building the crossrootfs location can be found at [cro
 Docker Images
 =============
 
-This table of images might often become stale as we change our images as our requirements change. The images used for our our official builds can be found in [the platform matrix](../../../../eng/pipelines/common/platform-matrix.yml) of our Azure DevOps builds under the `container` key of the platform you plan to build.
+This table of images might often become stale as we change our images as our requirements change. The images used for our our official builds can be found in [the pipeline resources](../../../../eng/pipelines/common/templates/pipeline-with-resources.yml) of our Azure DevOps builds under the `container` key of the platform you plan to build.
 
 | OS                          | Target Arch     | Image location                                                                                       | crossrootfs location | Clang Version |
 | --------------------------- | --------------- | ---------------------------------------------------------------------------------------------------- | -------------------- | ------------- |

docs/workflow/building/libraries/cross-building.md

@@ -1,8 +1,7 @@
-Cross Compilation for ARM on Linux
+Cross compile native runtime libraries on Linux
 ==================================
 
-It is possible to build CoreFx on Linux for arm, armel, or arm64 by cross compiling.
-It is very similar to the cross compilation procedure of CoreCLR.
+It is possible to build libraries on Linux for arm, armel, arm64 or other architectures by cross compiling. It is very similar to the cross compilation procedure of CoreCLR.
 
 Requirements
 ------------
@@ -11,7 +10,7 @@ You need a Debian based host, and the following packages need to be installed:
 
     $ sudo apt-get install qemu qemu-user-static binfmt-support debootstrap
 
-In addition, to cross compile CoreFX, the binutils for the target are required. So for arm you need:
+In addition, to cross compile libraries, the binutils for the target are required. So for arm you need:
 
     $ sudo apt-get install binutils-arm-linux-gnueabihf
 
@@ -23,109 +22,74 @@ and for arm64 you need:
 
     $ sudo apt-get install binutils-aarch64-linux-gnu
 
+and similar ones for other architectures.
 
-Generating the rootfs
+Generate the rootfs
 ---------------------
-The `eng/common/cross/build-rootfs.sh` script can be used to download the files needed for cross compilation. It will generate an Ubuntu 16.04 rootfs as this is what CoreFX targets.
+The `eng/common/cross/build-rootfs.sh` script can be used to download the files needed for cross compilation. It can generate rootfs for different operating systems and architectures, see `eng/common/cross/build-rootfs.sh --help` for more details.
 
-    Usage: ./eng/common/cross/build-rootfs.sh [BuildArch] [LinuxCodeName] [lldbx.y] [--skipunmount] --rootfsdir <directory>]
-    BuildArch can be: arm, armel, arm64, x86
-    LinuxCodeName - optional, Code name for Linux, can be: trusty, xenial(default), zesty, bionic, alpine. If BuildArch is armel, LinuxCodeName is jessie(default) or tizen.
-    lldbx.y - optional, LLDB version, can be: lldb3.9(default), lldb4.0, lldb5.0, lldb6.0 no-lldb. Ignored for alpine
+The `build-rootfs.sh` script might need to be launched as root, as it has to make some symlinks to the system. By default it generates the rootfs in `.tools/rootfs/<BuildArch>`, however this can be changed by setting the `ROOTFS_DIR` environment variable or by using `--rootfsdir`.
 
-The `build-rootfs.sh` script must be run as root, as it has to make some symlinks to the system. It will, by default, generate the rootfs in `cross/rootfs/<BuildArch>` however this can be changed by setting the `ROOTFS_DIR` environment variable or by using --rootfsdir.
+For example, to generate an arm Ubuntu 18.04 rootfs:
 
-For example, to generate an arm rootfs:
+    $ ./eng/common/cross/build-rootfs.sh arm bionic
 
-    $ sudo ./eng/common/cross/build-rootfs.sh arm
+And to generate the rootfs elsewhere:
 
-and if you wanted to generate the rootfs elsewhere:
+    $ ./build-rootfs.sh arm bionic --rootfsdir /mnt/rootfs/arm
 
-    $ sudo ./build-rootfs.sh arm --rootfsdir  /mnt/corefx-cross/arm
 
-
-Cross compiling for native CoreFX
+Compile native runtime libraries
 ---------------------------------
-Once the rootfs has been generated, it will be possible to cross compile CoreFX. If `ROOTFS_DIR` was set when generating the rootfs, then it must also be set when running `build.sh`.
-
-So, without `ROOTFS_DIR`:
-
-    $ ./src/Native/build-native.sh debug arm verbose cross
-
-And with:
-
-    $ ROOTFS_DIR=/mnt/corefx-cross/arm ./src/Native/build-native.sh debug arm verbose cross
 
-As usual the generated binaries will be found in `artifacts/bin/TargetOS.BuildArch.BuildType/native` as following:
-
-    $ ls -al ./artifacts/bin/Linux.arm.Debug/native
-    total 988
-    drwxrwxr-x 2 lgs lgs   4096  3  6 18:33 .
-    drwxrwxr-x 3 lgs lgs   4096  3  6 18:33 ..
-    -rw-r--r-- 1 lgs lgs  19797  3  6 18:33 System.IO.Compression.Native.so
-    -rw-r--r-- 1 lgs lgs 428232  3  6 18:33 System.Native.a
-    -rw-r--r-- 1 lgs lgs 228279  3  6 18:33 System.Native.so
-    -rw-r--r-- 1 lgs lgs  53089  3  6 18:33 System.Net.Http.Native.so
-    -rw-r--r-- 1 lgs lgs 266720  3  6 18:33 System.Security.Cryptography.Native.so
-    $ file ./artifacts/bin/Linux.arm.Debug/native/System.Native.so
-    ./bin/Linux.arm.Debug/native/System.Native.so:
-    ELF 32-bit LSB  shared object, ARM, EABI5 version 1 (SYSV),
-    dynamically linked, BuildID[sha1]=fac50f1bd657c1759f0ad6cf5951511ddf252e67, not stripped
-
-
-Compiling for managed CoreFX
+To build native runtime libraries for arm:
+
+    $ ROOTFS_DIR=`pwd`/.tools/rootfs/arm ./build.sh libs.native --cross --arch arm --librariesConfiguration Release
+
+Build artifacts can be found in `artifacts/bin/native/net7.0-<TargetOS>-<BuildArch>-<BuildType>/`:
+
+    $ ls artifacts/bin/native/net7.0-Linux-Release-arm/*
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Globalization.Native.a
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Globalization.Native.so
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Globalization.Native.so.dbg
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.IO.Compression.Native.a
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.IO.Compression.Native.so
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.IO.Compression.Native.so.dbg
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.IO.Ports.Native.a
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.IO.Ports.Native.so
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.IO.Ports.Native.so.dbg
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Native.a
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Native.so
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Native.so.dbg
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Net.Security.Native.a
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Net.Security.Native.so
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Net.Security.Native.so.dbg
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.a
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.so
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Security.Cryptography.Native.OpenSsl.so.dbg
+
+    $ file artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Native.so
+    artifacts/bin/native/net7.0-Linux-Release-arm/libSystem.Native.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=5f6f6f9c4012dffed133624867adf32ac2af130d, stripped
+
+
+Compile managed runtime libraries on Linux
 ============================
-The managed components of CoreFX are architecture-independent and thus do not require a special build for arm, armel or arm64.
+The managed components of libraries are architecture-independent and, thus, do not require a special build for arm, armel, arm64 or other architectures (this is true if ILLinker trimming is disabled with `/p:ILLinkTrimAssembly=false`).
 
 Many of the managed binaries are also OS-independent, e.g. System.Linq.dll, while some are OS-specific, e.g. System.IO.FileSystem.dll, with different builds for Windows and Linux.
 
-    $ ROOTFS_DIR=/mnt/corefx-cross/arm ./build.sh --arch arm
-
-You can also build just managed code with:
-
-    $ ./build.sh --arch arm /p:BuildNative=false
-
-The output is at `artifacts/bin/[BuildSettings]` where `BuildSettings` looks something like `net5.0-<TargetOS>-Debug-<Architecture>`. Ex: `artifacts/bin/net5.0-Linux-Debug-x64`. For more details on the build configurations see [project-guidelines](/docs/coding-guidelines/project-guidelines.md)
-
-Building corefx for Linux ARM Emulator
-=======================================
-
-It is possible to build corefx binaries (native and managed) for the Linux ARM Emulator (latest version provided here: [#5394](https://github.com/dotnet/runtime/issues/5394)).
-The `scripts/arm32_ci_script.sh` script does this.
-
-The following instructions assume that:
-* You have set up the extracted emulator at `/opt/linux-arm-emulator` (such that `/opt/linux-arm-emulator/platform/rootfs-t30.ext4` exists)
-* The mount path for the emulator rootfs is `/opt/linux-arm-emulator-root` (change this path if you have a working directory at this path).
-
-All the following instructions are for the Release mode. Change the commands and files accordingly for the Debug mode.
-
-To just build the native and managed corefx binaries for the Linux ARM Emulator, run the following command:
-```
-prajwal@ubuntu ~/corefx $ ./scripts/arm32_ci_script.sh \
-    --emulatorPath=/opt/linux-arm-emulator \
-    --mountPath=/opt/linux-arm-emulator-root \
-    --buildConfig=Release
-```
-
-The Linux ARM Emulator is based on the soft floating point and thus the native binaries are generated for the armel architecture. The corefx binaries generated by the above command can be found at `~/corefx/artifacts/bin/Linux.armel.Release`, `~/corefx/artifacts/bin/Linux.AnyCPU.Release`, `~/corefx/artifacts/bin/Unix.AnyCPU.Release`, and `~/corefx/artifacts/bin/AnyOS.AnyCPU.Release`.
-
+Build of managed runtime libraries requires presence of built native runtime libraries.
 
-Build corefx for a new architecture
-===================================
+To build managed runtime libraries for arm (architecture-dependent, can't be used on other architectures):
 
-When building for a new architecture you will need to build the native pieces separate from the managed pieces in order to correctly boot strap the native runtime. Instead of calling build.sh directly you should instead split the calls like such:
+    $ ./build.sh libs.sfx --arch arm --librariesConfiguration Release
 
-Example building for armel
-```
-src/Native/build-native.sh armel
---> Output goes to artifacts/bin/runtime/net5.0-Linux-Debug-armel
+Note that by default ILLinker trimming is enabled and libraries built above for arm can't be used on other arches. To build architecture-independent managed runtime libraries for arm:
 
-build /p:TargetArchitecture=x64 /p:BuildNative=false
---> Output goes to artifacts/bin/runtime/net5.0-Linux-Debug-x64
-```
+    $ ./build.sh libs.sfx --arch arm --librariesConfiguration Release /p:ILLinkTrimAssembly=false
 
-The reason you need to build the managed portion for x64 is because it depends on runtime packages for the new architecture which don't exist yet so we use another existing architecture such as x64 as a proxy for building the managed binaries.
+Build artifacts can be found in `artifacts/bin/microsoft.netcore.app.runtime.<TargetOS>-<BuildArch>/<BuildType>/runtimes/<TargetOS>-<BuildArch>/lib/net7.0/`. For more details on the build configurations see [project-guidelines](/docs/coding-guidelines/project-guidelines.md).
 
-Similar if you want to try and run tests you will have to copy the managed assemblies from the proxy directory (i.e. `net5.0-Linux-Debug-x64`) to the new architecture directory (i.e `net5.0-Linux-Debug-armel`) and run code via another host such as corerun because dotnet is at a higher level and most likely doesn't exist for the new architecture yet.
+Both native and managed runtime libraries can be built at the same time with:
 
-Once all the necessary builds are setup and packages are published the splitting of the build and manual creation of the runtime should no longer be necessary.
+    $ ROOTFS_DIR=`pwd`/.tools/rootfs/arm ./build.sh --cross --arch arm --librariesConfiguration Release --subset libs.native+libs.sfx

eng/CodeAnalysis.src.globalconfig

@@ -456,6 +456,9 @@ dotnet_diagnostic.CA2018.severity = warning
 # CA2019: Improper 'ThreadStatic' field initialization
 dotnet_diagnostic.CA2019.severity = warning
 
+# CA2020: Prevent behavioral changes
+dotnet_diagnostic.CA2020.severity = warning
+
 # CA2100: Review SQL queries for security vulnerabilities
 dotnet_diagnostic.CA2100.severity = none
 

eng/CodeAnalysis.test.globalconfig

@@ -453,6 +453,9 @@ dotnet_diagnostic.CA2018.severity = none
 # CA2019: Improper 'ThreadStatic' field initialization
 dotnet_diagnostic.CA2019.severity = none
 
+# CA2020: Prevent behavioral changes
+dotnet_diagnostic.CA2020.severity = none
+
 # CA2100: Review SQL queries for security vulnerabilities
 dotnet_diagnostic.CA2100.severity = none