Fix requires_lto targets needing lto set in cargo

[Flakebi]

Targets that set requires_lto = true were not actually using lto when compiling with cargo by default. They needed an extra lto = true in Cargo.toml to work.

Fix this by letting lto take precedence over the embed_bitcode flag when lto is required by a target.

If both these flags would be supplied by the user, an error is generated. However, this did not happen when lto was requested by the target instead of the user.

Fixes #148514
Tracking issue: #135024

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

[jieyouxu]

Hm, not entirely sure of the implications.
@rustbot reroll

[Flakebi]

The CI/tidy complain seems like a false-positive, the test uses --target, just not through //@ compile-flags:. Maybe that lint shouldn’t run on run-make-cargo tests?
(I’m happy to make the change, just want to get confirmation that it’s ok to do that.)

[jieyouxu]

The CI/tidy complain seems like a false-positive, the test uses --target, just not through //@ compile-flags:. Maybe that lint shouldn’t run on run-make-cargo tests? (I’m happy to make the change, just want to get confirmation that it’s ok to do that.)

Yes, I probably forgot to extend the tidy exception to run-make-cargo when I split the previous run-make test suite.

[bors]

☔ The latest upstream changes (presumably #150240) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Flakebi]

Rebased to fix conflicts with #150237, no other changes