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.
try-job: x86_64-mingw
readme: tweak wording around soundness
Miri *can* tell you whether your code is sound when it finds UB -- it's not sound in that case. It can give negative answers, just not positive ones.
Fix miri.bat to not exit unconditionally
#3703 has a small typo causing it to regress ./miri.bat to not working at all.
This PR fixes it. Tested on Windows 11, with stable toolchain missing as well as installed.
```test
./miri toolchain
error: toolchain 'stable-x86_64-pc-windows-msvc' is not installed
Failed to build miri-script. Is the 'stable' toolchain installed?
```
Closes#3714
Remove GetCurrentProcessId's frame_in_std check
Most of the support required to close#1727 was actually added a while back, in #2215.
However, for some reason, even though the Unix/Linux syscall equivalent has no `frame_in_std()` check, the Windows `GetCurrentProcessId` check did. While the vast majority of use cases use `std::process::id`, there's no particular reason to penalize any Windows code that is no_std or for whatever other reason choses to call the function directly (e.g. via the generated [windows-sys](https://docs.rs/windows-sys/latest/windows_sys/Win32/System/Threading/fn.GetCurrentProcessId.html) method). The emulation should still work fine. Given there's no reason not to, we might as well simplify the code a tiny bit and save that branch / frame check during runtime too.
This PR removes the `frame_in_std` restriction for `GetCurrentProcessId`, and also moves it into the environment related shim section per discussion in https://github.com/rust-lang/miri/issues/1727#issuecomment-2184679952.
Still passes existing tests/pass/getpid.rs test.
Closes#1727 unless we wish to give a dummy value when isolated, which we don't seem to want to do at this time.
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 #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
Support fetching `Attribute` of items.
Fixes [https://github.com/rust-lang/project-stable-mir/issues/83](https://github.com/rust-lang/project-stable-mir/issues/83)
`rustc_ast::ast::Attribute` doesn't impl `Hash` and `Eq`. Thus it cannot be directly used as key of `IndexMap` in `rustc_smir::rustc_smir::Tables` and we cannot define stable `Attribute` as index to `rustc_ast::ast::Attribute` like `Span` and many other stable definitions.
Since an string (or tokens) and its span contain all info about an attribute, I defined a simple `Attribute` struct on stable side.
I choose to fetch attributes via `tcx::get_attrs_by_path()` due to `get_attrs()` is marked as deprecated and `get_attrs_by_name()` cannot handle name of multiple segments like `rustfmt::skip`.
r? `@celinval`
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](34ef8f5441). However, it's also [not really compatible with Stacked Borrows](https://github.com/rust-lang/unsafe-code-guidelines/issues/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](https://github.com/rust-lang/rust/issues/126814#issuecomment-2183816373) 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```
patchable-function-entry: Add unstable compiler flag and attribute
Tracking issue: #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.
bump strip-ansi-escapes
This bumps `strip-ansi-escapes` to remove arrayvec from it's deps (https://github.com/luser/strip-ansi-escapes/pull/8)
Should Cargo.lock be commited too to track it's working state?
changelog: none
ast: Standardize visiting order
Order: ID, attributes, inner nodes in source order if possible, tokens, span.
Also always use exhaustive matching in visiting infra, and visit some discovered missing nodes.
Unlike https://github.com/rust-lang/rust/pull/125741 this shouldn't affect anything serious like `macro_rules` scopes.
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>
