Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 ILLink targets and tests #3125
Add ILLink targets and tests #3125
Changes from all commits
7470658
e3262fc
075b137
1c98c83
e475c44
bdbe81c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 don't think you need this anymore if we can merge #3152 first
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.
@nguerrera mind if I do that in a follow-up PR? I'd like to get this change in sooner rather than later.
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.
Sure
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.
Are these files? It is weird to have a "public" item and property of the same name. Is there a reason why the user wouldn't provide these directly as items?
Also, item names are generally singular (though it is not 100% consistent) so this is more of a nit.
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.
They are files. In the OOB package we supported this to make it easy to test on the command-line. I'll get rid of this in a follow-up and we can iterate there.
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.
The linker works with
ResolvedFileToPublish
as input, and I think that's the way it should be for now.But I'm curious why crossgen works differently. Crossgen targets run after
_ComputeResolvedFilesToPublishTypes
target, and processes/updates the files bifurcated into_ResolvedFileToPublishPreserveNewest
and_ResolvedFileToPublishAlways
items. However, the processing /input-outputs for the two lists there are similar. So, why doesn't crossgen similarly processResolvedFileToPublish
?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.
Good question - @fadimounir can you answer this?
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.
When I started implementing this, i was under the impression that I would need to add some logic to the crossgen task to distinguish between the 2 lists, and only compile things in the PreserveNewest if they were out of date.
Things have evolved since then, and thinking about it now, I believe we should be able to just make crossgen work with the 'ResolvedFileToPublish', before the split that '_ComputeResolvedFilesToPublishTypes' does.
I'll make that change. For the linker, i think this looks correct.
The linker does one operation with multiple input files. Crossgen does multiple operations, each with its own input file, so splitting the 'ResolvedFilesToPublish' by type doesn't make sense here i believe
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.
This is the kind of change that would be undesirable if we moved this targets file to the ILLink nuget package, because if the names here change, this would be breaking.
@nguerrera, how can we ensure that name changes here won't break other tools/SDKs that depend on this? CI tests good enough?
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.
if other sdks to depend on it is expected, it should be public and follow backward compact rules
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.
This is exactly why we are putting the targets portion in the SDK. The contract to the linker is pure, no global mutations. Yes, other tools might do this sort of thing, but we specifically cut defining a strict contract for such tools. The linker will be first class and any mutation of the build state will happen in dotnet/sdk. This + sufficient tests will ensure that we don't just break the linker as we used to when it was it's own nuget package. I want to make it possible to write these sort of things outside of the sdk, but it is a hard problem and specifically not one we are going to solve as part of this work.