-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Updated Microsoft.CodeAnalysis.PublicApiAnalyzers to latest stable #41115
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
Conversation
29b9559
to
abd697f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how to review this thoroughly since the changes mix the different cases. Might be worthwhile splitting out (for example) the removal of true duplicate lines from the rest. The next stage might be to handle nullability changes for existing methods (remove a large number of *REMOVED*
lines from the Unshipped files while annotating the Shipped files correctly). Finally, could do the Microsoft.CodeAnalysis.PublicApiAnalyzers version bump while adding default constructors.
Another debatable issue is how to handle default constructors we shipped in .NET 6.0.0. They all show up in PublicAPI.Unshipped.txt files in this PR.
This is actually very close to passing CI validation. Congrats @BrennanConroy❕ Should decide a few things like
|
Any update on if when we might get this merged? |
The only real regression IMO is the forwarded types being messy. I think the issue with REMOVED for non-nullable annotated APIs when we annotate them as nullable is fine, it should just be this one time cost.
I don't feel strongly about figuring out the "correct" solution to this, I think it's completely fine to leave them in the unshipped file and move on with our lives.
Good luck 😄 , I'm not going to spend a couple hours trying to have separate commits for "removing duplicates", adding default ctors, etc. |
abd697f
to
42957bd
Compare
PR updated with split commits.
The third one is a bit odd since there are still APIs with ~, basically just kept modifying based on the analyzers errors over and over until the build passed. I think we should remove all ~ from our shipped files at the end of 7.0. |
Thanks for the splitting @BrennanConroy❕ I'll try to look at this today but would also like to hear from @DamianEdwards, @dotnet/aspdoi and / or @dotnet/aspnet-build on the other questions. @jmarolf any chance the package will be or has been fixed enough to avoid these shenanigans❔ |
Which shenanigans? We accept PRs :) Microsoft.CodeAnalysis.PublicApiAnalyzers is just infrastructure that roslyn wrote to meet our own needs. |
That's not great for a public project we and others have taken a hard dependency on. The tooling behaves rather differently in v3.3.0 and v.3.3.3. We didn't make those changes. @dotnet/aspnet-build @dotnet/aspdoi any suggestions for alternative public API verifiers❔ We can't go back to 😦 |
Probably also worth discussing why the supported features for this don't meet your needs https://docs.microsoft.com/dotnet/fundamentals/package-validation/overview |
Doesn't package validation only confirm that a package has the same surface area across the TFMs & RIDs it supports? We also need to verify that we don't change API surface in servicing branches, which I'm not sure the package validation tool does. |
Do you mean added to .shipped files (for ones from pre-7.0)? I'd be alright with this PR if that was the case |
We have that enabled in this repo, have a few CompatibilitySuppressions.xml files, and enable baseline version validation in servicing builds but…
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Am I correct all of the "duplicate" entries removed in the second commit are shipped signatures lacking all nullable annotations, *REMOVED*
signatures for the same, or *REMOVED*
signatures containing a leading ~
but also the correct nullable annotations❔ If that's the case, the analyzer must previously have ignored the nullable annotations when eliminating duplicates. I can see that as fixing a bug but the default constructor thing isn't great and I haven't looked at the third commit.
@SteveSandersonMS @mattleibow has dotnet/maui had any issues with the 3.3.3 version of |
@SteveSandersonMS @mattleibow see also #41115 (comment) |
42957bd
to
d288ceb
Compare
Sorry, coming back to this after a bit. Other than rebasing on 'main', any changes in the first two commits @BrennanConroy❔ |
Oh, the "new but old" default constructors remain in PublicApi.Unshipped.txt files. As @wtgodbe suggested, those should all or mostly be n Shipped files. |
~Microsoft.AspNetCore.Authentication.WsFederation.WsFederationOptions.ConfigurationManager.get -> Microsoft.IdentityModel.Protocols.IConfigurationManager<Microsoft.IdentityModel.Protocols.WsFederation.WsFederationConfiguration!>! | ||
~Microsoft.AspNetCore.Authentication.WsFederation.WsFederationOptions.ConfigurationManager.set -> void |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where did these supposedly non-null-aware additions come from❔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I understand most of the third commit though
- It's not clear to me why there remains so much in the PublicAPI.Unshipped.txt files. Did that much really change since 6.0.0❔
- I don't know the code nor what's actually changed aside from nullability touch-ups that should now be handled exclusively in the PublicAPI.Shipped.txt files. Suggest we need area owners to look closely at the PublicAPI.Unshipped.txt files.
~Microsoft.AspNetCore.Http.Features.FeatureReference<> (forwarded, contained in Microsoft.Extensions.Features) | ||
~Microsoft.AspNetCore.Http.Features.FeatureReferences<> (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReference<T> (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReference<T>.Fetch(Microsoft.AspNetCore.Http.Features.IFeatureCollection! features) -> T? (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReference<T>.Update(Microsoft.AspNetCore.Http.Features.IFeatureCollection! features, T feature) -> T (forwarded, contained in Microsoft.Extensions.Features) | ||
static readonly Microsoft.AspNetCore.Http.Features.FeatureReference<T>.Default -> Microsoft.AspNetCore.Http.Features.FeatureReference<T> (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReference<T>.FeatureReference() -> void (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache> (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Cache -> TCache? (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Collection.get -> Microsoft.AspNetCore.Http.Features.IFeatureCollection! (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.FeatureReferences(Microsoft.AspNetCore.Http.Features.IFeatureCollection! collection) -> void (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Fetch<TFeature, TState>(ref TFeature? cached, TState state, System.Func<TState, TFeature?>! factory) -> TFeature? (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Fetch<TFeature>(ref TFeature? cached, System.Func<Microsoft.AspNetCore.Http.Features.IFeatureCollection!, TFeature?>! factory) -> TFeature? (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Initalize(Microsoft.AspNetCore.Http.Features.IFeatureCollection! collection) -> void (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Initalize(Microsoft.AspNetCore.Http.Features.IFeatureCollection! collection, int revision) -> void (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.FeatureReferences() -> void (forwarded, contained in Microsoft.Extensions.Features) | ||
Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Revision.get -> int (forwarded, contained in Microsoft.Extensions.Features) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you mentioned this earlier but to confirm: Forwarding a type no longer implicitly forwards its members❔ That's very messy if so because it's not possible to forward a subset of the members w/o something weird going on (maybe partial classes but I doubt it). Feels like a regression in the analyzer.
Yes? Besides the struct ctors, there were a bunch of new APIs.
I don't know the exact behavior here, but the fix I found was to explicitly add any new API in the forwarded type to the old forward-from assembly as well as the actual location the type lives now.
I think most of the changes were due to APIs either being marked as nullable in 7.0 or having nullable changes (such as when Extensions was nullable attributed and affected a lot of our APIs). The new version of the analyzer does not like having the same API only differ by nullability it seems like. |
d288ceb
to
c327fe1
Compare
Default ctors moved to the shipped file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes seem reasonable. Will there be manual changes needed going forward? Might be worth letting people know that any active changes will need to be rebased/regenerated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh, sorry this took longer than I expected. Nothing much to comment on 😸
c327fe1
to
cb817a9
Compare
This is looking close 🎉 |
You'll have to merge @dougbu to override the Code Check task |
I'll check in a few hours (have an appointment I need to leave for soon) and get this in before @JamesNK nullifies something else 😃 |
…otnet#41115) * Adding default ctors * Remove duplicates * normalize nullable * fixup * fb
No description provided.