Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[main] Update dependencies from dotnet/installer #5870

Merged
merged 7 commits into from
Apr 30, 2021

Conversation

dotnet-maestro[bot]
Copy link
Contributor

@dotnet-maestro dotnet-maestro bot commented Apr 26, 2021

This pull request updates the following dependencies

From https://github.com/dotnet/installer

  • Subscription: 6548876b-06a1-4ab6-a5a5-08d8ed868088
  • Build: 20210429.1
  • Date Produced: 4/29/2021 8:46 AM
  • Commit: 0b60950dad3cd50b07e130568454a33e058e2507
  • Branch: refs/heads/main

…210426.1

Microsoft.Dotnet.Sdk.Internal
 From Version 6.0.100-preview.4.21221.10 -> To Version 6.0.100-preview.5.21226.1
sbomer added a commit to sbomer/xamarin-android that referenced this pull request Apr 27, 2021
This allows the custom steps to be added using the supported mechanism,
one at a time, instead of injecting them using reflection.

Depends on dotnet#5870.
Latest ILLink appears to not support net5.0 anymore:

    error NU1202: Package Microsoft.NET.ILLink 6.0.100-preview.5.21227.1 is not compatible with net5.0
@jonpryor
Copy link
Member

er, what?

/Users/builder/.dotnet/sdk/5.0.201/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.TargetFrameworkInference.targets(141,5):
error NETSDK1045: The current .NET SDK does not support targeting .NET 6.0.
Either target .NET 5.0 or lower, or use a version of the .NET SDK that supports .NET 6.0.

Rebuilding, just in case?

@jonpryor
Copy link
Member

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pjcollins
Copy link
Member

The parent dependency update I made to the linker package version here may have been jumping the gun a bit... I didn't realize this new package required targeting .NET 6. This also has implications for #5806. Maybe we should install a "global" .NET 6 preview that can be used to build against at this point...

@sbomer
Copy link
Member

sbomer commented Apr 28, 2021

In case it helps in the short term, the change to target net6 was reverted for other reasons (but I believe it's just a matter of time until it goes back in). @vitek-karas

@jonathanpeppers
Copy link
Member

Tried darc update-dependencies --channel ".NET 6" --name Microsoft.Dotnet.Sdk.Internal:

-    <MicrosoftDotnetSdkInternalPackageVersion>6.0.100-preview.5.21227.1</MicrosoftDotnetSdkInternalPackageVersion>
+    <MicrosoftDotnetSdkInternalPackageVersion>6.0.100-preview.5.21228.7</MicrosoftDotnetSdkInternalPackageVersion>

It doesn't think there is a newer Microsoft.NET.ILLink.Tasks yet.

I think we could try again tomorrow, or install .NET 6 on the failing test jobs?

@pjcollins
Copy link
Member

I'm also working on a PR to build our .NET 6 content against .NET 6 Preview 3 which will hopefully be ready shortly, and will allow us to continue targeting net6.0 in this project.

dotnet-maestro bot and others added 2 commits April 29, 2021 10:57
…210429.1

Microsoft.Dotnet.Sdk.Internal
 From Version 6.0.100-preview.4.21221.10 -> To Version 6.0.100-preview.5.21229.1
* Remove `$(OutputType)` from a class library project
@jonpryor
Copy link
Member

I think we could try again tomorrow, or install .NET 6 on the failing test jobs?

I think "tomorrow" was today, and today's auto-bump didn't resolve the problem either.

How do we get this building?

@jonathanpeppers
Copy link
Member

I think the plan is to land #5891 then we can come back to this.

@jonathanpeppers jonathanpeppers merged commit 351a7ba into main Apr 30, 2021
@jonathanpeppers jonathanpeppers deleted the darc-main-0c32f9d6-417c-4614-8f51-1d5961ee5ccc branch April 30, 2021 19:13
sbomer added a commit to sbomer/xamarin-android that referenced this pull request May 5, 2021
This allows the custom steps to be added using the supported mechanism,
one at a time, instead of injecting them using reflection.

Depends on dotnet#5870.
jonpryor pushed a commit that referenced this pull request Jun 2, 2021
Context: dotnet/linker#1953
Context: dotnet/linker#1774
Context: dotnet/linker#1774 (comment)
Context: dotnet/linker#1979
Context: dotnet/linker#2019
Context: dotnet/linker#2045
Context: dotnet/java-interop@2573dc8
Context: #5870
Context: #5878

Update the custom linker steps to use the new `IMarkHandler` API
which runs logic during "MarkStep".

(See [this list][0] of pipeline steps for additional context.)

As part of this, I've removed the workaround that loads all referenced
assemblies up-front and simplified some of the linker MSBuild targets.
Some of the `MonoDroid.Tuner` steps were duplicated and changed to
implement the new `IMarkHandler` interface, to avoid touching the
`MonoDroid.Tuner` code.

In my analysis of the custom steps, most of them "just work" if we
call them only for marked members, because they ultimately either:

  - Just call `AddPreserved*()` to conditionally keep members of types
    (which with the new API will just happen when the type is marked)

  - In the case of `FixAbstractMethodsStep()`, inject missing interface
    implementations which will only be kept if they are marked for some
    other reason.

Most of the steps have been updated in a straightforward way based on
the above.

The exceptions are:

  - `AddKeepAlivesStep` needs to run on all code that survived
    linking, and can run as a normal step.

  - `ApplyPreserveAttribute`: this step globally marks members with
    `PreserveAttribute`.
    - The step is only active for non-SDK link assemblies.  Usually we
      root non-SDK assemblies, but it will be a problem if linking all
      assemblies.
    - For now, I updated it to use the new custom step API on assembly
      mark -- so it will scan for the attribute in all marked
      assemblies -- but we should investigate whether this is good
      enough.
    - This can't be migrated to use `IMarkHandler` because it needs
      to scan code for attributes, including unmarked code.

  - `PreserveExportedTypes`: similar to the above, this globally marks
    members with `Export*Attribute`.  It's used for java interop in
    cases where the java methods aren't referenced statically, like
    from xml, or for special serialization methods.
    - It's only active for non-SDK assemblies, so like above it will
      be a problem only if linking all assemblies.
    - Like above, I've made it scan marked assemblies.

  - `PreserveApplications`: globally scans for `ApplicationAttribute`
    on types/assemblies, and sets the `TypePreserve` annotation for
    any types referenced by the attribute.
    - This step technically does a global scan, but it's likely to work
      on "mark type"/"mark assembly", as `ApplicationAttribute` is only
      used on types/assembies that are already kept.
    - I've updated it to use the new `IMarkHandler` API.

Additionally, as per dotnet/java-interop@2573dc8c, stop using
`TypeDefinitionCache` everywhere and instead use `IMetadataResolver`
to support caching `TypeDefinition`s across shared steps.
For .NET 6, `LinkContextMetadataResolver` implements the
`IMetadataResolver` interface in terms of `LinkContext`.

[0]: https://github.com/mono/linker/blob/main/src/linker/Linker/Driver.cs#L714-L730
@github-actions github-actions bot locked and limited conversation to collaborators Jan 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants