Rename linker to illink

[tlakollo]

As suggested in #77569 (comment)
The linker name could be confusing since the term is used broadly to define different things. Therefore there has been an initial effort to rename linker to illink as a project. Part of it has been to rename the target folder inside #78049 to point to src/tools/illink instead of src/tools/linker and add subsets that are tools.illink and tools.illinktests
There are still a lot of places in which the linker name still exists (documentation and code) and renaming it to ILLink would homologize the terminology for the project.

[danmoseley]

Does the linker actually link, or do we only use it to trim? Should be be renamed trimmer?

[vitek-karas]

It only trims, but the ILLink term is used in so many places that changing that would be really hard (MSBuild, SDK, public MSBuild properties, documentation, everywhere in the code, ...). While not ideal it's definitely better than the current "linker" name which is very confusing especially in cases where there's potentially platform linker as well (like mono AOT where both "linkers" actually run).

[danmoseley]

I recognize we can't wave a wand and rename everything but it feels like we could do more to be consistent with the parts that are most visible to users. One of our goals is to make trimming a more normal part of the .NET ecosystem, and I imagine most users have not yet been exposed to it and whatever terms we use today. Is it possible it will be easier to make trimming more accessible if we do more to consistently avoid the term linker, even if we can't eliminate it?

Today eg., users pass /p:publishtrimmed=true , but may choose <TrimmerDefaultAction>link</TrimmerDefaultAction> (I don't have a mental picture of why it is called link here), and create configuration files with XML tag <linker>. The docs use various terms eg., IL trimmer trimmer and also I see Some of the options mention ILLink, which is the name of the underlying tool that implements trimming. For more information about the underlying tool, see the [Trimmer documentation](https://github.com/dotnet/linker/tree/main/docs). Going to those docs, there are 280 hits on "linker" and 8 on "trimmer". It talks about passing "_ExtraTrimmerArgs" to the "linker" or setting "TrimmerRootAssembly" in "PrepareForILLink" ..

It feels like we're making things unnecessarily confusing by perpetuating both... I'm confused myself

I don't think stuff like the MSBuild task name or our code matters much, I have in mind consistently avoiding the term linker in the context of trimming in command line flags and project properties, error messages, and documentation.

[vitek-karas]

We're actually pretty good with this. Almost everything normal users would find is using "trim". We're moving away from some of the old configuration options - like TrimmerDefaultAction=link, we now have TrimMode=full which is basically the same thing, but much more understandable.

We're also reasonably good at separation of the concept (trimming) from the tool (illink) and we've been trying to keep that separation. This is important because we have more than on tool in this space. The NativeAOT compiler is also a trimmer and it reacts to all of the "Trimmer*" properties, but it should not react to anything "ILLink*".

I have in mind consistently avoiding the term linker in the context of trimming in command line flags and project properties, error messages, and documentation.

This is definitely true and we're trying to stick to that - all public facing docs, messages, ... should use the term "Trim". The only exception are some MSBuild properties which are like low lever knobs for the ILLink tool itself, some of those might have the "ILLink" prefix. I don't expect many users to ever learn about those, let alone use them.

So what this basically means is that I don't think we need to change the end user terminology - it's been "trim" pretty much everywhere. And thus the discussion is basically about the name of the trimmer tool - currently that name is ILLink. It's not ideal because of the word "Link" in it, but as tools goes it's not that bad. You could also argue that we should then rename NativeAOT compiler from ilc to nativeaotcompiler, and crossgen2 to r2rcompiler and so on. Definitely all reasonable, but we're probably not going to do it, since the effort is probably not worth it.

[danmoseley]

What about the configuration files, which have the root <linker> . Will users be exposed to those, when they suppress messages or force root things?

(I do agree that the name of the tool itself doesn't matter much if users don't call it directly, similar to crossgen as you point out.)

[vitek-karas]

I would hope that very few users are exposed to the XML files.

Our hope and guidance is to use code to express dependencies.

Suppressing warnings is a bad idea, but if you have to do it, then it should be done via an attribute. Currently the only reason to use XML for that is if you need to suppress a warning in an assembly you don't build - which should hopefully be rare. (and we might want to look into adding attribute support even for that if it becomes broader problem).

Rooting things should be done in code - pretty much always. If it can't be done via normal IL references, then use DynamicDependency attribute. There are some improvements we might want to do in this area (allow assembly level usage of the attribute), but this is already covering almost all cases.

The last thing XMLs are used for are feature switches. There's no "code first" way to do these currently. That said we would very much like to add a way to do these via attributes (there are already issues around these ideas in the linker repo). Also so far feature switches seem to be very rare externally - I've heard only about one use case.

That said, changing the linker element name would be quite easy (just support two names). There are other problems with the XMLs which are probably more important - they use Cecil's syntax to refer to things, which is really weird in some cases and more importantly nobody outside of Cecil users would know about it. Ideally it should support also the reflection syntax one day.

[danmoseley]

Currently the only reason to use XML for that is if you need to suppress a warning in an assembly you don't build - which should hopefully be rare.

Perhaps we can remove most of the ILLink* files in src/libraries.

That said, changing the linker element name would be quite easy (just support two names).

That would be my 2c -- even if folks don't use them, they'll probably see them in the docs.

[vitek-karas]

Perhaps we can remove most of the ILLink* files in src/libraries.

We've been trying to reduce these, with various levels of success. Most of the "descriptors" should be removed (with the exception of CoreLib which has a lot of those and thus it's more work to remove, also there's no much incentive to do so). We should have no "attribute" XMLs which we're shipping, again with the exception of CoreLib where they're used for mobile/blazor scenarios to tell the linker to remove some attributes which are otherwise preserved. We do have quite a few "build only" attribute XMLs - these are used to suppress trim warnings in assemblies we didn't annotate yet. There are several "substitution" XMLs, since they're our only mechanism for feature switches, this is expected.

[vitek-karas]

I created dotnet/linker#3114 for the root element rename.

[sbomer]

Going to those docs, there are 280 hits on "linker" and 8 on "trimmer". It talks about passing "_ExtraTrimmerArgs" to the "linker" or setting "TrimmerRootAssembly" in "PrepareForILLink"

I think it would be worth replacing "linker" with "illink" even in our internal docs to make this less confusing for people who land there.

[tlakollo]

Closed via #82050