[main] Update dependencies from dotnet/linker

[dotnet-maestro]

This pull request updates the following dependencies

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

• Subscription: 0d6d6ae4-f71f-4395-53e6-08d8e409d87d
• Build: 20230112.1
• Date Produced: January 12, 2023 8:47:58 AM UTC
• Commit: 10bb5ae1476941dbdfe3afa327db01750232db8a
• Branch: refs/heads/main

• Updates:
  • Microsoft.NET.ILLink.Tasks: from 7.0.100-1.22606.1 to 8.0.100-1.23062.1

[lewing]

failures look widespread

[vitek-karas]

Cecil is completely broken. This change (the upstream version of that change) jbevain/cecil#888 shows that it actually breaks even Cecil's own tests. The produced IL is somehow corrupted on the byte level.

Using latest linker from main on a hello world ends up with an app which can't even start the runtime (probably fails to load CoreLib). And it crashes crossgen as seen in the CI here.

We've reverted the change to new Cecil in linker here: dotnet/linker#3174
Once that flows into this PR it should start working again.

@sbomer - dotnet/cecil#55 introduced the break, can you please look into it?

Technically it would be great if we actually tried to run trimmed code in the linker repo, but given that linker will move to runtime repo in the next couple of weeks it's probably moot point (well, once we switch the runtime to use live builds of linker anyway). /cc @tlakollo just as an FYI

[sbomer]

Looking into it

[ViktorHofer]

The dependency update should be unblocked now.

[MichalStrehovsky]

Technically it would be great if we actually tried to run trimmed code in the linker repo, but given that linker will move to runtime repo in the next couple of weeks it's probably moot point

I'm surprised none of the tests in the illinker repo caught this. It would be good to understand why. I was helping @tlakollo troubleshoot this exact same (🥲) issue today because he ran into it when linker from the dotnet/runtime repo was getting consumed in the SDK repo. It took a bit to connect the dots. The runtime repo hasn't picked up the Cecil fix yet, so that explains things.

The method bodies were completely wrong - illinker testing usually doesn't look at the method bodies, but at least the constant propagation tests do. I would expect us to see it there - were we just unlucky?

[vitek-karas]

The method bodies were completely wrong - illinker testing usually doesn't look at the method bodies, but at least the constant propagation tests do. I would expect us to see it there - were we just unlucky?

Either that or Cecil could read the data it wrote... not sure. I didn't dig into it, mainly because the real test is to actually run the assembly - we discussed doing that many times, but never happened. And now when linker is in runtime it sort of decreases in priority a bit, because we will end up running linked code immediately in the CI.