Refactor linker code

[bjorn3]

This merges LinkerInfo into CrateInfo as there is no reason to keep them separate. LinkerInfo::to_linker is merged into get_linker as both have different logic for each linker type and to_linker is directly called after get_linker. Also contains a couple of small cleanups.

See the individual commits for all changes.

[rust-highfive]

Some changes occured to rustc_codegen_cranelift

cc @bjorn3

[rust-highfive]

r? @davidtwco

(rust-highfive has picked a reviewer for you, use r? to override)

[petrochenkov]

r? @petrochenkov

[petrochenkov]

r=me with fulldeps tests fixed.

[bjorn3]

I would like to do a perf run first. I have been bitten by a perf regression during refactorings more than once.

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 25e45ba with merge 0a0da8444906b2540c2e9df61115d7fb40e2b4a0...

[bors]

☀️ Try build successful - checks-actions
Build commit: 0a0da8444906b2540c2e9df61115d7fb40e2b4a0 (0a0da8444906b2540c2e9df61115d7fb40e2b4a0)

[rust-timer]

Queued 0a0da8444906b2540c2e9df61115d7fb40e2b4a0 with parent b09dad3, future comparison URL.

[rust-timer]

Finished benchmarking try commit (0a0da8444906b2540c2e9df61115d7fb40e2b4a0): comparison url.

Summary: This benchmark run did not return any significant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

[bjorn3]

Mostly improvements up to 0.7%. Only a couple regressions up to 0.4%.

[bjorn3]

@bors r=petrochenkov

[bors]

📌 Commit 25e45ba has been approved by petrochenkov

[nagisa]

I would like to see the commit messages expanded with more of "why" in addition to "what". For example, what is the motivation to move LinkerInfo into CrateInfo? I would also like to see some discussion on why this is the overall direction we want to be taking.

[petrochenkov]

I think the changes are reasonable because LinkerInfo generally doesn't make sense as a separate structure.

Yes, it contains some pre-computed properties of the compilation session used when building linker invocation, but it's not clear why they should be separated from similar properties from (maybe misnamed) CrateInfo.

[nagisa]

Yeah I don't mean to push back against the changes it's just something that makes it easier to understand them. Something like your comment is pretty good and I think it's worthwhile to at least copy it over to the pr description so that it at least ends up in the merge commit.

…

On Tue, 6 Jul 2021, 23:50 Vadim Petrochenkov, ***@***.***> wrote: I think the changes are reasonable because LinkerInfo generally doesn't make sense as a separate structure. Yes, it contains some pre-computed properties of the compilation session used when building linker invocation, but it's not clear why they should be separated from similar properties from (maybe misnamed) CrateInfo. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#86911 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFFZUXB7YLU6MGRZFHKPH3TWNUC3ANCNFSM4746PUYQ> .

[bjorn3]

Edited the PR description to describe the reason behind some changes.

[bors]

⌛ Testing commit 25e45ba with merge b20e3ff...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing b20e3ff to master...