People are having trouble when they don't want to build `lld` for their custom
distribution tarballs even with `lld = false` in their config.toml. This is because
it is not controlled by `lld_enabled` flag. This change ensures that `llvm:Lld`
is controlled by lld configuration.

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Make sure lld is enabled for dist profile unless it is explicitly disabled.

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Signed-off-by: onur-ozkan <work@onurozkan.dev>

`-Z patchable-function-entry` works like `-fpatchable-function-entry`
on clang/gcc. The arguments are total nop count and function offset.

See MCP rust-lang/compiler-team#704

See [RFC](https://github.com/maurer/rust-rfcs/blob/patchable-function-entry/text/0000-patchable-function-entry.md) (yet to be numbered)

TODO before submission:
* Needs an RFC
* Improve error reporting for malformed attributes

tests

Removes an `unsafe` in favor of just using `String` methods.

Co-authored-by: Ralf Jung <post@ralfj.de>

Currently bootstrap doesn't use any inner paths from rust-analyzer and
bootstrap with `ShouldRun::create_or_deps`.

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Signed-off-by: onur-ozkan <work@onurozkan.dev>

…s-pr, r=estebank,workingjubilee

patchable-function-entry: Add unstable compiler flag and attribute

Tracking issue: rust-lang#123115

Add the -Z patchable-function-entry compiler flag and the #[patchable_function_entry(prefix_nops = m, entry_nops = n)] attribute.
Rebased and adjusted the canditate implementation to match changes in the RFC.

…e, r=Kobzol

make cargo submodule optional

Right now, we fetch the cargo submodule no matter what, even if the command we are running doesn't need it (e.g., `x build compiler library`). This PR changes that to only fetch the cargo submodule when it's necessary.

For more context, see the zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Why.20is.20cargo.20always.20checked.20out.3F

…=Kobzol

ignore `llvm::Lld` if lld is not enabled

People are having trouble ([ref. zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/MSVC.20Runtime.20mismatch.20when.20building.20LLD)) when they don't want to build `lld` for their custom distribution tarballs even with `lld = false` in their config.toml. This is because it is not controlled by `lld_enabled` flag. This change ensures that `llvm:Lld` is controlled by lld configuration.

Additionally, `lld = true` is set by default for dist profile, because we have been building it all along and this maintains that behavior.

core: avoid `extern type`s in formatting infrastructure

``@RalfJung`` [said](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Use.20of.20.60extern.20type.60.20in.20formatting.20machinery/near/446552837):

>How attached are y'all to using `extern type` in the formatting machinery?
Seems like this was introduced a [long time ago](rust-lang@34ef8f5). However, it's also [not really compatible with Stacked Borrows](rust-lang/unsafe-code-guidelines#256), and only works currently because we effectively treat references-to-extern-type almost like raw pointers in Stacked Borrows -- which of course is unsound, it's not how LLVM works. I was planning to make Miri emit a warning when this happens to avoid cases like [this](rust-lang#126814 (comment)) where people use extern type specifically to silence Miri without realizing what happens. but with the formatting machinery using  extern type, this warning would just show up everywhere...
>
> The "proper" way to do this in Stacked Borrows is to use raw pointers (or `NonNull`).

This PR does just that.

r? ``@RalfJung``

… r=cuviper

Simplify `str::clone_into`

Removes an `unsafe` in favor of just using `String` methods.

…s, r=oli-obk

Tighten `fn_decl_span` for async blocks

Tightens the span of `async {}` blocks in diagnostics, and subsequently async closures and async fns, by actually setting the `fn_decl_span` correctly. This is kinda a follow-up on rust-lang#125078, but it fixes the problem in a more general way.

I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters.

r? ```@estebank``` or ```@oli-obk``` or someone else on wg-diag or compiler i dont really care lol