Linker into runtime diff

.github/CODEOWNERS

@@ -83,6 +83,14 @@
 
 /eng/pipelines/**/*wasm* @radical
 
+# Linker codeowners
+/src/tools/linker/ @marek-safar
+/src/tools/linker/src/analyzer/ @radekdoulik
+/src/tools/linker/src/ILLink.Tasks/ @sbomer
+/src/tools/linker/src/ILLink.RoslynAnalyzer/ @sbomer
+/src/tools/linker/src/linker/ @marek-safar @mrvoorhe
+/src/tools/linker/test/ @marek-safar @mrvoorhe
+
 # Obsoletions / Custom Diagnostics
 
 /docs/project/list-of-diagnostics.md                @jeffhandley

.gitignore

@@ -342,9 +342,6 @@ jit32
 # performance testing sandbox
 sandbox
 
-#IL linker for testing
-linker
-
 # Symbolic link for the shared portion of CoreLib to make grep/findstr work for runtime devs
 #
 # On Windows, make your own by running these commands from the repo root:
@@ -365,4 +362,4 @@ src/coreclr/System.Private.CoreLib/common
 
 # Temporary artifacts from local libraries stress builds
 .dotnet-daily/
-run-stress-*
+run-stress-*

Directory.Build.props

@@ -84,6 +84,7 @@
     <MonoProjectRoot>$([MSBuild]::NormalizeDirectory('$(MSBuildThisFileDirectory)', 'src', 'mono'))</MonoProjectRoot>
     <InstallerProjectRoot>$([MSBuild]::NormalizeDirectory('$(MSBuildThisFileDirectory)', 'src', 'installer'))</InstallerProjectRoot>
     <WorkloadsProjectRoot>$([MSBuild]::NormalizeDirectory('$(MSBuildThisFileDirectory)', 'src', 'workloads'))</WorkloadsProjectRoot>
+    <ToolsProjectRoot>$([MSBuild]::NormalizeDirectory('$(MSBuildThisFileDirectory)', 'src', 'tools'))</ToolsProjectRoot>
     <SharedNativeRoot>$([MSBuild]::NormalizeDirectory('$(RepoRoot)', 'src', 'native'))</SharedNativeRoot>
     <RepoToolsLocalDir>$([MSBuild]::NormalizeDirectory('$(MSBuildThisFileDirectory)', 'tools-local'))</RepoToolsLocalDir>
     <RepoTasksDir>$([MSBuild]::NormalizeDirectory('$(MSBuildThisFileDirectory)', 'src', 'tasks'))</RepoTasksDir>

THIRD-PARTY-NOTICES.TXT

@@ -1175,3 +1175,26 @@ As an exception, if, as a result of your compiling your source code, portions
 of this Software are embedded into a machine-executable object form of such
 source code, you may redistribute such embedded portions in such object form
 without including the above copyright and permission notices.
+
+License for Jb Evain
+---------------------
+
+Copyright (c) 2006 Jb Evain ([email protected])
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+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 WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

src/tools/linker/docs/design/constant-propagation-and-branch-removal.md → docs/design/tools/linker/constant-propagation-and-branch-removal.md

@@ -12,7 +12,7 @@ Method can return constant value if its code will always return the same value (
     public bool Is32Bit { get => false; }
 ```
 
-On 64bit platforms the property is compiled with constant value, and ILLInk can determine this. It's also possible to use substitutions to overwrite method's return value to a constant via the [substitutions XML file](../data-formats.md#substitution-format). 
+On 64bit platforms the property is compiled with constant value, and ILLInk can determine this. It's also possible to use substitutions to overwrite method's return value to a constant via the [substitutions XML file](../../../tools/linker/data-formats.md#substitution-format).
 
 If such method is used in another method and it influences its return value, it can mean that the caller method will itself always return the same value. For example:
 
@@ -77,7 +77,7 @@ Processing the stack is a loop where:
 * Loop until stack is empty
 * The top of the stack is peeked (not actually popped) and the method there is processed
   1. The last attempt version of the method is set to the current version of the stack (for loop detection, see below)
-  2. The method's body is scanned and all callees which can be used for constant propagation are detected  
+  2. The method's body is scanned and all callees which can be used for constant propagation are detected
       * If the called method is already processed its value is used (if it has one)
         * There's an optimization here where methods are only marked as processed without analyzing for their return value. If such method is encountered here, the return value analyzer will run in-place to determine the value of the method (and the result is stored)
       * If the called method is not yet processed and is not on the stack, it's added to the top of the stack

src/tools/linker/docs/design/redundant-suppressions.md → docs/design/tools/linker/redundant-suppressions.md

@@ -37,7 +37,7 @@ The warning suppression could present a challenge to the software development li
     }
 ```
 
-If we keep the warning suppression on this trimmer-compatible code, we will end up with a potentially dangerous case. Should we later add some trimmer-incompatible code within the scope of the suppression which triggers the suppressed warning, we will not be informed about it during the trimming process. That is, the warning issued by the linker will be silenced by the suppression we left over and it will not be displayed. This may result in a scenario in which the trimming completes with no warnings, yet errors occur at runtime. 
+If we keep the warning suppression on this trimmer-compatible code, we will end up with a potentially dangerous case. Should we later add some trimmer-incompatible code within the scope of the suppression which triggers the suppressed warning, we will not be informed about it during the trimming process. That is, the warning issued by the linker will be silenced by the suppression we left over and it will not be displayed. This may result in a scenario in which the trimming completes with no warnings, yet errors occur at runtime.
 
 This can be illustrated with the following example. Let us extend the above code to also print the value of `suffix` field.
 
@@ -59,13 +59,13 @@ Now the code is again trimmer-incompatible, the `GetField("suffix")` call will t
 
 In order to avoid the above scenario, we would like to have an option to detect and report the warning suppressions which are not tied to any warnings caused by trim-incompatible patterns.
 
-This may be achieved by extending the linker tool functionality to check which suppression do in fact suppress warnings and reporting those which do not. 
+This may be achieved by extending the linker tool functionality to check which suppression do in fact suppress warnings and reporting those which do not.
 
 Running the tool with the redundant warning suppressions detection enabled will report all of the warning suppressions which do not suppress any warnings. The way to turn it on is TBD.
 
 ***NOTE:*** We will only process suppressions produced by the linker, other suppressions will be ignored.
 ### Example:
-Let us again consider the example of the trimmer-compatible code with a redundant warning suppression. 
+Let us again consider the example of the trimmer-compatible code with a redundant warning suppression.
 
 ```csharp
     [UnconditionalSuppressMessage("trim", "IL2070", Justification = "DynamicDependency attribute will instruct the linker to keep the public methods on NameProvider.")] // This should be removed

src/tools/linker/docs/design/reflection-flow.md → docs/design/tools/linker/reflection-flow.md

@@ -177,7 +177,7 @@ More details discussed in https://github.com/dotnet/runtime/issues/35339.
 
 This is an existing custom attribute (known as `DynamicDependencyAttribute`) understood by the linker. This attribute allows the user to declare the type name, method/field name, and signature (all as a string) of a method or field that the method dynamically depends on.
 
-When the linker sees a method/constructor/field annotated with this attribute as necessary, it also marks the referenced member as necessary. It also suppresses all analysis within the method. 
+When the linker sees a method/constructor/field annotated with this attribute as necessary, it also marks the referenced member as necessary. It also suppresses all analysis within the method.
 See issue https://github.com/dotnet/runtime/issues/30902 for details.
 
 ## Case study: Custom attributes

src/tools/linker/docs/design/trimmed-assemblies.md → docs/design/tools/linker/trimmed-assemblies.md

@@ -25,7 +25,7 @@ To enable aggressive trimming instead of assembly-level trimming, we provide a p
 ### `PrepareForILLink`
 There is a public target `PrepareForILLink` that runs before the `ILLink` target, and provides a convenient place to hook into the pipeline to modify metadata for trimming. SDK components can use this as an extension point via `BeforeTargets` and `AfterTargets`.
 
-The global `TrimMode` may be set any time before `PrepareForILLink` runs, which sets it to a default value if not set previously. 
+The global `TrimMode` may be set any time before `PrepareForILLink` runs, which sets it to a default value if not set previously.
 
 ### `ManagedAssemblyToLink`
 The `PrepareForILLink` has a dependency that creates the ItemGroup `ManagedAssemblyToLink`, which represents the set of assemblies that will be passed to the linker. Custom targets may modify `IsTrimmable` and `TrimMode` metadata on these assemblies before `PrepareForILLink`, which sets the assembly action based on this metadata, or they may modify the metadata after `PrepareForILLink` has run.

src/tools/linker/docs/README.md → docs/tools/linker/README.md

@@ -13,5 +13,5 @@ View the official trimming docs at [docs.microsoft.com](https://docs.microsoft.c
 - [Authoring Custom Steps](custom-steps.md)
 
 ## Design Docs
-- [Trimmer Steps Explained](design/steps-explained.md)
-- [Reflection Handling](design/reflection-flow.md)
+- [Trimmer Steps Explained](../../design/tools/linker/steps-explained.md)
+- [Reflection Handling](../../design/tools/linker/reflection-flow.md)

src/tools/linker/docs/custom-steps.md → docs/tools/linker/custom-steps.md

@@ -54,4 +54,4 @@ The common operation in the custom steps is to run additional checks on the IL t
 required constraints. The outcome of such operation is then usually some indication to the end user about
 the incompatible code. This can be done by reporting the error or warning message using `context.LogMessage`
 method. It's good practice to use error or warning code which does not conflict with existing codes as
-listed [here](/docs/error-codes.md).
+listed [here](error-codes.md).