Update AST validation module docs
Drive-by doc update for AST validation pass:
- Syntax extensions are replaced by proc macros.
- Add rationale for why AST validation pass need to be run
post-expansion and why the pass is needed in the first place.
This was discussed during this week's [rustc-dev-guide reading club](https://rust-lang.zulipchat.com/#narrow/stream/196385-t-compiler.2Fwg-rustc-dev-guide), and the rationale was explained by cc ``````@bjorn3.``````
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
When the LoongArch targets were first introduced, the LLVM support was
still immature and various tools were not supported on LoongArch.
Nowadays most infra is in place, so it is time to enable them on
LoongArch to provide a better experience for users of these targets.
Plus, the profiler support is needed by Chromium, so better provide it
in the official artifacts.
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.
Instead of keeping a list of architectures which have native support
for 64-bit atomics, just use #[cfg(target_has_atomic = "64")] and its
inverted counterpart to determine whether we need to use portable
AtomicU64 on the target architecture.
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`
