-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Add LinkabilityChecker tool #40342
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
Add LinkabilityChecker tool #40342
Conversation
@pranavkm After removing the wasm/mono attributes the project generates an error:
There are no references to those projects in aspnetcore. Any idea what is wrong? If not, who should I talk to? |
You might want to also get rid of this test
|
c942ae2
to
5b61a70
Compare
@JamesNK I'm gonna guess there's a reference to these assemblies in the graph somewhere (maybe a |
FYI - I force pushed to this branch after rebasing on main |
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.
src/Shared
seems reasonable to me
I don't feel strongly about this but what is "shared" about this project❔ Not quite understanding how it fits into this repo in the first place and where it might fit otherwise. I'd feel better if the project were in its own src/ directory than under Shared. |
There isn't anything shared. Basically, this is a project that checks linking warnings in shipping projects. It will end up referencing most shipping projects. It's generic, but it isn't itself shared. An alternative location I considered was /src/Tools. It is kind of a tool for checking for linker warnings and generating linker suppression. |
You're a ⭐ |
src/Tools/ would work for me. Other options might be src/Testing/test/ or src/CheckLinkability/. |
@JamesNK / @dougbu I was playing around with this change and came up with pranavkm@0a96a3d. The idea is to use Thoughts? |
The idea sounds reasonable though I suggest things may be simpler if the metadata were collected when we run CodeGen.proj rather than added in a new corner of our infrastructure and re-generated every time trimmability is tested. Put another way, I agree w/ the direction but suggest getting there by a slightly different route. The targets in CodeGen.proj and the supporting bits at the bottom of ResolveReferences.targets could easily be extended to collect More generally, I'd like to be fairly sure we do not limit checking assemblies are trimmable to the shared framework projects. I could see us wanting to ensure something that ships only in a package is and remains trimmable. |
@pranavkm I've moved the app to tools. Feel free to apply your changes. I added a couple of projects, up until I hit one that generated trim warnings: |
@@ -136,7 +137,8 @@ public void SetValue(object instance, object? value) | |||
/// <param name="typeInfo">The type info to extract property accessors for.</param> | |||
/// <returns>A cached array of all public properties of the specified type. | |||
/// </returns> | |||
public static PropertyHelper[] GetProperties(TypeInfo typeInfo) | |||
public static PropertyHelper[] GetProperties( |
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 PropertyHelper in general is incompatible with trimming.
@@ -95,6 +95,7 @@ public RouteValueDictionary() | |||
/// property names are keys, and property values are the values, and copied into the dictionary. | |||
/// Only public instance non-index properties are considered. | |||
/// </remarks> | |||
[RequiresUnreferencedCode("RouteValueDictionary uses reflection to generate the route values.")] | |||
public RouteValueDictionary(object? values) |
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 we might want new public API ctors for RouteValueDictionary
.
public RouteValueDictionary(object? values);
+public RouteValueDictionary(IDictionary<string, object> values);
Copying values from a IDictionary
is fine. Copying values via reflection from public properties seems incompatible with trimming.
@@ -12,7 +12,7 @@ Microsoft.AspNetCore.Http.Features.FeatureCollection | |||
<IsAspNetCoreApp>true</IsAspNetCoreApp> | |||
<GenerateDocumentationFile>true</GenerateDocumentationFile> | |||
<PackageTags>aspnetcore</PackageTags> | |||
<Nullable>enable</Nullable> |
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.
Why is nullable being removed?
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.
Nullable is now turned on by default for all projects. Removing because it's redundent.
Addresses #27384
Replicate https://github.com/dotnet/aspnetcore/tree/5760f2864016081a142642b417db17e5340a1d67/src/Components/WebAssembly/testassets/WasmLinkerTest
I've removed the wasm specific build attributes:
For lack of anywhere else to put it, I've placed the new testassets project in Shared. @aspnet-build let me know if you'd like it moved somewhere else.