| Age | Commit message (Collapse) | Author |
|---|
|
* Update dependencies from https://github.com/dotnet/arcade build 20190514.13
- Microsoft.DotNet.Arcade.Sdk - 1.0.0-beta.19264.13
* Update dependencies from https://github.com/dotnet/arcade build 20190516.2
- Microsoft.DotNet.Arcade.Sdk - 1.0.0-beta.19266.2
* Sweep attributes on GenericParameters and InterfaceImplementations
This fixes test failures that show up due to NullableAttribute with
recent versions of .NET Core (https://github.com/mono/linker/pull/570)
* Increase line count limit for reduced tracing test
* Add test for sweeping attributes on GenericParameters
|
|
With the latest cecil update in
https://github.com/mono/linker/pull/471, we are using SDK-style
projects and building cecil for netstandard2.0, so the workaround for
https://github.com/dotnet/sdk/issues/3194 is no longer necessary.
|
|
* Use SDK-style projects for linker and tests
* Clean up linker project file
Separate out the illink build properties from the monolinker
properties. Also disable building illink for net46 on unix/core
msbuild, which doesn't work due to missing reference assemblies. This
check is more specific than what we used to have, so that illink can
potentially be built with the mono runtime.
Building this project with "nuget restore" and "msbuild" will only
work with the default configuration because nuget restore does not set
the configuration and would see a different target framework from msbuild.
* Fix assembly title and description for illink
* Fix debug and optimization info for illink configurations
* Remove references to old illink solutions
* Update cecil submodule to latest mono/cecil
* Fix typo
* Update cecil configurations in illink.sln
* Fix cecil strongname build failure with arcade
Work around https://github.com/dotnet/arcade/issues/2321
* Remove unused configs from monolinker.sln
Also add a missing release config for cecil
* Set PublicKey and PublicKeyToken in cecil overrides
|
|
* Match SDK dependency versions
* Redistribute System.Reflection.Metadata.dll
* Exclude runtime assets on msbuild references
* Work around https://github.com/dotnet/sdk/issues/3194
|
|
* Handle long paths in ILLink.Tasks LinkTask
LinkTask invocation involving long-paths (with spaces) failed because
the arguments to dotnet.exe Illink.dll are not within quotes.
This change fixes the problem.
Ideally, the LinkTask should use a response file, instead of the long
command line. However, dotnet.exe currently doesn't support response files.
https://github.com/dotnet/cli/issues/7657
* Update LinkTask.cs
|
|
|
|
The package should include Mono.Cecil.dll.
|
|
This also adds a status badge for the .NET Core build.
|
|
We have a class library profile that doesn't support exceptions. In order for MethodAction.ConvertToThrow to work with this profile I will need to be able to override enough of the pieces so that I can inject Environment.FailFast instead of throw new exception.
|
|
For https://github.com/dotnet/sdk/pull/3125.
This most notably adds a net472 build of ILLink.Tasks, and modifies Sdk.props to import the correct build of the tasks, depending on the MSBuild runtime type. This makes it possible to use the linker tasks on desktop MSBuild once again. Regardless of the MSBuild runtime, illink.dll will run on .NET Core. We set 'rollForwardOnNoCandidateFx' to allow running on .NET Core 3 (even though illink.dl is built targeting netcoreapp2.0).
This change removes many workarounds from the old packaging logic, as we can now use NuGet extension points and avoid using a custom .nuspec.
|
|
|
|
Instance method bodies do not need to be marked until an instance of the type could exist. Any instance methods that were marked on types that are never instantiated will be converted to a throw.
* A number of existing tests needed to be updated to avoid lazy body marking
* Add a new CodeOptimization to allow disabling this mechanism. Reasoning was, (1) it's simple to support an option. (2) It may be helpful if it causes problems. (3) I could see using this option to make writing certain tests easier.
* Marking of some small bodies will not be deferred. The idea is that the size cost of some methods is less than converting them to a throw. So we might as well leave them alone. See `IsWorthConvertingToThrow`
* Factored out `MarkAndCacheNotSupportedCtorString` since I need to call it from multiple places now.
* Expose the `RewriteBody*` methods in CodeRewriterStep for overriding. A few motivations for this. (1) We have a runtime that doesn't support exceptions. When we target that runtime we will need to override `ConvertToThrow` with something else. (2) I will likely override all of the `RewriteBody*` methods so that I can record which bodies are changed and hook it up to logging mechanisms that we have.
Note. This PR has a test that depends on https://github.com/mono/linker/pull/501 . That PR will need to land first and I will need to rebase after that lands. There will be 1 failing test until that happens.
|
|
Fixes build issue with arcade update. Since we are still using our own
.nuspec (rather than letting the nuget targets generate one), we also
need to specify the license in our custom .nuspec.
|
|
The test `NeverInstantiatedTypeWithBaseInCopiedAssembly` is the case that would hit an invalid IL bug.
Made other changes to how the marking of virtuals due to a preserved parent works when the type has not been instantiated yet.
|
|
|
|
When publishing a framework-dependent .NET Core app, the framework
implementation is not available during publish, and is represented to
the compiler by reference assemblies. Conceptually, reference
assemblies only represent surface area for compilation. Their
implementations can vary depending on the platform where the app is
eventually run.
There's no good way to detect whether an assembly is a reference
assembly. "True" reference assemblies will have a
ReferenceAssemblyAttribute, but the SDK's ReferencePath ItemGroup will
often contain implementation assemblies that are passed to the
compiler as references.
Ideally the linker would be able to resolve types defined in reference
assemblies without looking at IL they contain. For now, we just pass
along any reference assemblies that aren't also part of the
implementation set given to the linker, specifying the "skip"
action. This will prevent them from being placed in the output, but
they may still be analyzed.
As long as any implementation dlls in ReferenceAssemblyPaths are also
present in AssemblyPaths, this should match the desired
behavior. Exceptions to this should be rare.
|
|
The introduction of `MethodWithoutParameters()` in this test causes the linker to write invalid IL. When the linker sweeps this method, a bug causes it to keep the attribute on the return type parameter. However, the attribute type itself is removed (causing it to become detached from its declaring type).
https://jenkins.mono-project.com/job/test-linker-pull-request/759/console:
```
09:58:19 1) Failed : Mono.Linker.Tests.TestCases.All.OnlyKeepUsed.UnusedAttributeOnReturnTypeIsRemoved
09:58:19 Invalid IL detected in /tmp/linker_tests/output/library.dll
09:58:19 FAIL: Invalid CustomAttribute row 0 Type field 0x00000022
09:58:19 Error count: 1
09:58:19 at Mono.Linker.Tests.TestCasesRunner.PeVerifier.CheckAssembly (Mono.Linker.Tests.Extensions.NPath assemblyPath) [0x00099] in <0aac952fa2cb4e07af00f27b39783fd3>:0
09:58:19 at Mono.Linker.Tests.TestCasesRunner.PeVerifier.Check (Mono.Linker.Tests.TestCasesRunner.LinkedTestCaseResult linkResult, Mono.Cecil.AssemblyDefinition original) [0x00098] in <0aac952fa2cb4e07af00f27b39783fd3>:0
09:58:19 at Mono.Linker.Tests.TestCasesRunner.ResultChecker.Check (Mono.Linker.Tests.TestCasesRunner.LinkedTestCaseResult linkResult) [0x00095] in <0aac952fa2cb4e07af00f27b39783fd3>:0
09:58:19 at Mono.Linker.Tests.TestCases.All.Run (Mono.Linker.Tests.TestCases.TestCase testCase) [0x00019] in <0aac952fa2cb4e07af00f27b39783fd3>:0
09:58:19 at Mono.Linker.Tests.TestCases.All.AttributesTests (Mono.Linker.Tests.TestCases.TestCase testCase) [0x00001] in <0aac952fa2cb4e07af00f27b39783fd3>:0
```
|
|
For some reason the linker logic in Xamarin.iOS relies on this ResolveFromAssemblyStep.ProcessLibrary()
to overwrite the assembly action. If we don't do that it'd link an assembly
that should really be copied.
I couldn't yet figure out how to fix this so best to revert this change
(it was mostly needed to write a test for https://github.com/mono/linker/pull/497
but I didn't get to that yet).
Partially reverts 9b26a0973a5439ab79135ba826c539768ed7455c.
|
|
* Clean up SetAction a little
* Rename `LinkContext.SetAction` to `LinkContext.SetActionToDefault` since that's what it is actually doing. Setting the action to the specified user or core action.
* Add a new `LinkContext.SetAction` that will ensure the assembly is registered and has SafeReadSymbols called. I hit an issue in our linker where I had early phase steps calling `context.Annotations.SetAction`. If you call that directly you can get into a situation where `RegisterAssembly` does not call `SafeReadSymbols` because `SeenFirstTime` is returning true. And when that happens, you end up breaking symbol linking for that assembly. My hope is that this new `LinkContext.SetAction` is a slightly less error prone way of setting the action on assembly in a step that runs before `LoadReferenceStep`
* Update LinkContext.cs
|
|
This PR fixes https://github.com/mono/linker/issues/465
The linker is incorrectly removing base class members
that fullfil an interface when generics are involved.
|
|
When a custom link action for an assembly is passed to the linker on the
commandline we'd override it with `Copy` in `ProcessLibrary`.
Instead we now check whether we already have an assembly action before
setting it.
LoadI18nAssemblies used this to force `Copy` on the I18N assemblies
by calling `ProcessLibrary` with `RootVisibility.Any` so we need to set
the assembly action explicitly to maintain that behavior.
|
|
This enables the unit tests to run on .NET Core. CodeDom compilation doesn't exist on core, so I've added the ability to compile in-process with Roslyn APIs. This still uses NUnit, using a recent version of NUnit package references with "dotnet test". This doesn't change how tests run on mono.
Finding the right reference assemblies for compilation is a bit different on .NET Core. As described in https://github.com/dotnet/roslyn/wiki/Runtime-code-generation-using-Roslyn-compilations-in-.NET-Core-App, they can either be found using packages (what the SDK does), or we can just compile against the implementation assemblies. In this change, I'm compiling against implementation assemblies, since that's fairly similar to what the tests do on mono, where they find them in the GAC.
For mono, the common references only included mscorlib. For .NET Core, I'm getting the common references from the "Trusted Platform Assemblies" (TPA) of the test process. As a result, package references of the test project become references during testcase compilation. Explicit references specified via `ReferenceAttribute` in a testcase are looked for alongside the host process's implementations as well (since we have no way to resolve a reference from just the filename since there is no GAC).
Other changes:
- Roslyn outputs the `DebuggableAttribute` by default but mcs does not, so when running on .NET Core, we don't check for the `DebuggableAttribute`.
- Check for core types in `System.Private.CoreLib` instead of `mscorlib`.
- There are some more edge cases that I'm in the process of cleaning up and will update soon.
At the moment, I'm trying to get the tests up and running, and I'm using plenty of compile-time conditions to modify the behavior on core. It would be nice not to have to do this - I haven't given it much thought, but maybe we could provide an abstraction that contains knowledge of the platform libraries, so that we don't have to have a hard dependency on `"mscorlib.dll"` and `"System.Private.CoreLib.dll"` everywhere? @mrvoorhe please let me know if you have any thoughts. Does the approach I'm taking so far seem sane to you?
@marek-safar
|
|
This wasn't causing any issues today. ValueType is Serializable and that leads to `MarkStep.MarkSerializable` being called, which ensures `ValueType::.ctor()` is marked, which ensures `ValueType` is marked as instantiated.
However, we have a smaller class library profile that does not have the serializable code. As a result ValueType is not marked as instantiated. This leads to struct overrides of object members being removed.
Having so much hinge on ValueType being Serializable seems fragile. So rather than depend on that, let's also consider `ValueType` one of the things that should always be marked instantiated if it appears.
|
|
Fix a bug caused by parameter types not being taken into account in `AllPossibleStackTypes`
|
|
This is similar to https://github.com/mono/linker/pull/430.
We hit the same issue when `AssemblyAction` is `Save` instead of `Copy`
since this enum value was missing in `MarkStep.IsFullyPreserved()`.
|
|
Equivalent logic is going to be in the R2R tool. The FilterByMetadata line is necessary because it used to be in ILLink.CrossGen.targets.
/cc @fadimounir
|
|
Adding Sdk.props to be imported by the dotnet/sdk
|
|
* Run illink out-of-process by implementing ToolTask
* Publish illink with runtimeconfig.json and deps.json
* Ensure that publish workaround runs after runtime files exist
The workaround for https://github.com/dotnet/sdk/issues/1675 must run
after GenerateBuildDependencyFile and
GenerateBuildRuntimeConfigurationFiles to ensure that the deps.json
and runtimeconfig.json files exist at that time.
* Avoid string concatenation when using StringBuilder
|
|
This will show up in the msbuild output with a higher importance by
default, and may also align more closely with the expectations of
command line users.
@marek-safar the other option is to make this the behavior of monolinker as well. What do you think?
|
|
We already have this behavior for unresolved methods. This introduces
the same for fields to prevent some more resolution failures in cases
where the assembly containing the field's type is not present at link
time.
|
|
* Use 3.0 preview SDK to build illink
* Respond to SDK changes in conflict resolution targets
* Respond to SDK changes to publish assembly resolution
* Work around duplicate items introduced by an sdk change
See https://github.com/dotnet/sdk/issues/3007
* Remove dependency on GetRuntimeLibraries
Instead, use RuntimePackAssets resolved by the SDK
|
|
* Add .yml build definition
* Add linux linker build
* Remove left-over pool section
* Set helixRepo for telemetry
* Add windows build, and use recommended pool
* Add dotnet-core blob feed
* Add helix variable group
* Checkout submodules
* Remove dependency on NuGet.ProjectModel
* Specify release configuration
* Sign with 3rd-party certs
* Fix signing props
* Publish build logs
* Set _DotNetPublishToBlobFeed
* Use new variable syntax
* Use _BuildConfig variable for arcade templates
* Set msbuild variable for blob feed publish
* Add blob feed url
* Add blob feed token and pass build id
* Add _TeamName for microbuild
* Fix syntax
* Set DotNetSignType from _SignType
* Publish only on windows
* Only publish build asset manifest on windows
* Only pass signing variables to windows
* Add displayName for build command
* Put publish args in a variable
* Remove Nuget.ProjectModel dependency
* Use jobs.yml template and add ci build
* Disable custom certificate for ILLink.CustomSteps signing
* Generate assembly info for ILLink.CustomSteps
* Remove unnecessary properties from ILLink.CustomSteps project
* Clean up Signing.props
|
|
This uses arcade to bootstrap the dotnet cli, and enables optionally building illink.sln with arcade.
- `eng/dotnet.{sh/ps1}` replace `corebuild/dotnet.{sh/ps1}`, and bootstrap using arcade scripts
- References to the bootstrapping scripts have been updated
- Directory.Build.props and Directory.Build.targets import arcade for all SDK-style projects when `ArcadeBuild` is `true`
- The net46 build of ILLink.Tasks has been disabled to work around the lack of configuration/target-framework inference (due to cecil not using SDK projects yet). This makes it possible to run "dotnet pack" on the solution or to pack using arcade.
- Arcade versioning files have been introduced, and ILLink.Tasks always gets its version number from these, even when building with a plain .NET SDK (rather than the arcade SDK)
- Works around signing properties that are otherwise overridden due to cecil's nonstandard import order (it imports the arcade properties after setting its own project properties)
- Disables a warning that is an error in the more recent toolset used by arcade
- Re-orders some projects in illink.sln to work around build issues where solution configurations aren't always applied to child projects. This seems to build the dependent projects last, ensuring that they are built with the solution configuration.
|
|
Until I can make more progress on SDK-style projects (see https://github.com/mono/linker/pull/471), I'll begin trying to set up a build of illink using arcade and the old-style projects. In this change I'm getting rid of the scattered linker.sln files in favor of monolinker.sln for monolinker, and illink.sln for the illink/ILLink.Tasks build.
|
|
When processing overrides on a type that is never instantiated,
it is only safe to skip marking of an interface method if the interface
implementation corresponding to that method is *not* marked *and*
no other interface implementations that implement that interface are marked
|
|
|
|
This organizes the source and test projects as follows:
- source projects go in `src/project/projectfile.csproj`
- test projects go in `test/project/projectfile.csproj`
The uniform layout of projects is part of the arcade onboarding (see https://github.com/mono/linker/issues/452).
|
