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

Reference ILLink analyzer matching ILLink version #32045

Merged
merged 11 commits into from
May 31, 2023
Merged

Conversation

sbomer
Copy link
Member

@sbomer sbomer commented Apr 25, 2023

Fixes dotnet/runtime#84119.

We were already referencing the analyzer from the ILLink package on net8.0, so there we only needed to remove the bundled analyzer to fix dotnet/runtime#84119.

For older TFMs, we currently use the latest analyzer that's bundled with the SDK. I replaced this with logic to use a packagreference, matching the version of ILLink. Note that with this change, when targeting downlevel TFMs the 8.0 SDK will use the 7.0 analyzer instead of the 8.0 analyzer that we use today.

@sbomer sbomer requested review from AntonLapounov and a team as code owners April 25, 2023 21:37
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-ILLink untriaged Request triage from a team member labels Apr 25, 2023
@sbomer sbomer requested review from vitek-karas and agocke April 25, 2023 21:38
Comment on lines +716 to +718
var analyzerPackage = new TaskItem("Microsoft.NET.ILLink.Analyzers");
analyzerPackage.SetMetadata(MetadataKeys.Version, packVersion);
implicitPackageReferences.Add(analyzerPackage);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious: where do we download this from? It seems it's not on NuGet... is the SDK adding some other public feeds for this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's downloaded from NuGet: https://www.nuget.org/packages/Microsoft.NET.ILLink.Analyzers/

For internal builds the specific version would be available on an internal feed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That package was submitted by mistake - it only has one 8.0 preview version, it definitely doesn't contain downlevel versions.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll ask for it to be uploaded to nuget.

Comment on lines -123 to -131
<Dependency Name="Microsoft.NET.ILLink.Analyzers" Version="8.0.100-1.23067.1">
<Uri>https://github.com/dotnet/linker</Uri>
<Sha>c790896f128957acd2999208f44f09ae1e826c8c</Sha>
</Dependency>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the corresponding version number be removed from Versions.props? Otherwise I believe it will still be there and available for use, but won't ever get updated.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like we were using the ILLink.Tasks package version, and this Version.Details.xml version was never used. I removed the ILLink.Tasks packagereference and cleaned up some left-over analyzer layout logic that was using it.

I left in the ILLink.Tasks entry in Versions.props and Version.Details.xml even though these are technically unused. We test with an ILLink.Tasks version matching MicrosoftNETCoreAppRefPackageVersion, which should always be the same, but it kind of seems nice to make the dependency explicit at least in Versions.props. Let me know if you'd prefer me to remove it and I will.

Comment on lines +716 to +718
var analyzerPackage = new TaskItem("Microsoft.NET.ILLink.Analyzers");
analyzerPackage.SetMetadata(MetadataKeys.Version, packVersion);
implicitPackageReferences.Add(analyzerPackage);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's downloaded from NuGet: https://www.nuget.org/packages/Microsoft.NET.ILLink.Analyzers/

For internal builds the specific version would be available on an internal feed.

@sbomer
Copy link
Member Author

sbomer commented Apr 26, 2023

This is failing in a test that checks that incremental publish of a single-file doesn't re-generate the single-file if there are no changes. It is caused by #28661.

<_IsTrimmingEnabled Condition="'$(_IsTrimmingEnabled)' == '' And ('$(PublishTrimmed)' == 'true' Or '$(IsTrimmable)' == 'true')">true</_IsTrimmingEnabled>
<_IsTrimmingEnabled Condition="'$(_IsTrimmingEnabled)' == '' And (
'$(PublishTrimmed)' == 'true' Or
'$(PublishSingleFile)' == 'true' Or
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we rename _IsTrimmingEnabled? It doesn't seem like a good name anymore, if we are setting it to true when I only set PublishSingleFile.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dotnet/runtime uses that property already. @sbomer can you please take care of updating it when these changes are being consumed? https://github.com/dotnet/runtime/blob/98dd1e83ba8b17299af9d3d78000f8a9c000a12e/eng/illink.targets#L5C1-L6

@sbomer sbomer enabled auto-merge (squash) May 31, 2023 15:55
@sbomer sbomer merged commit b59a9ed into dotnet:main May 31, 2023
@mthalman
Copy link
Member

mthalman commented Jun 1, 2023

@sbomer - This causes a failure when using the SDK containing these changes to build the runtime repo. This is affecting source-build. Can you investigate please? I have this issue logged with details: dotnet/source-build#3490

sbomer added a commit that referenced this pull request Jun 12, 2023
Before net8.0, the illink analyzer shipped as a separate package
from ILLink.Tasks. #32045 added
logic to reference the separate package for tfms less than
net8.0.

This change tweaks the logic to be based on the package version
resolved from KnownILLinkPack, rather than the tfm. This makes it
possible to define KnownILLinkPack to pull in the latest
analyzer, as a workaround when targeting unsupported TFMs. The
scenario is still considered unsupported, but this at least makes
it possible to work around.

A new testcase shows the steps necessary to use the latest illink
analyzer on a netstandard2.x project.
sbomer added a commit to sbomer/sdk that referenced this pull request Oct 3, 2023
Up to .NET 7, the analyzers versioned with the SDK (so you would always
get the latest analyzers). This allowed using the analyzers (and related
options which enable the analyzers) even on older TFMs.

dotnet#32045 changed to versioning the
analyzers with the target framework, but still allowed use of the analyzers
on target frameworks where the .NET 7 ILLink pack was made available
for backwards compatibility.

This change removes such backwards compat by treating the analyzers
as unsupported for target frameworks before the framework was annotated
with the relevant attributes.

PublishTrimmed/PublishSingleFile/PublishAot used to enable the corresponding
analyzers. With this change, we now need to avoid failing
PublishTrimmed/PublishSingleFile for older TFMs that supported these publish
options, but don't support the analyzers.
sbomer added a commit that referenced this pull request Oct 5, 2023
Up to .NET 7, the analyzers versioned with the SDK (so you would always
get the latest analyzers). This allowed using the analyzers (and related
options which enable the analyzers) even on older TFMs.

#32045 changed to versioning the
analyzers with the target framework, but still allowed use of the analyzers
on target frameworks where the .NET 7 ILLink pack was made available
for backwards compatibility.

This change removes such backwards compat by treating the analyzers
as unsupported for target frameworks before the framework was annotated
with the relevant attributes. This increases the scope of the warning added in
#29441 and #34077 to also warn for these unsupported
TFMs.

The first commit adds testcases to show the old behavior. The second commit
implements the new behavior and shows the changes to these testcases.

PublishTrimmed/PublishSingleFile/PublishAot used to enable the corresponding
analyzers. With this change, we now need to avoid failing
PublishTrimmed/PublishSingleFile for older TFMs that supported these publish
options, but don't support the analyzers. This change handles that by only
defaulting the `Enable*Analyzer` settings based on the publish settings for
TFMs where the analyzers are known to be supported.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-ILLink untriaged Request triage from a team member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ILLink analyzer and code fixer passed twice to the csc
6 participants