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`
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.
The docs for the LoongArch targets are a bit dated since their
introduction, and the prose has some room for improvement as well.
Streamline a bit, referring to the neighboring targets' docs, and
provide up-to-date information as much as I can come up with.
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>
Fix doc_markdown DevOps false positive
This fixes an issue where the word "DevOps" ends up as a false positive for the `doc_markdown` lint.
In a doc comment like this
```rust
/// Call the Azure DevOps REST API.
pub fn example() {}
```
the word "DevOps" is highlighted as something which should be in backticks.
```
warning: item in documentation is missing backticks
--> src/lib.rs:1:20
|
1 | /// Call the Azure DevOps REST API.
| ^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_markdown
= note: requested on the command line with `-W clippy::doc-markdown`
help: try
|
1 | /// Call the Azure `DevOps` REST API.
| ~~~~~~~~
warning: `example` (lib) generated 1 warning (run `cargo clippy --fix --lib -p example` to apply 1 suggestion)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s
```
This could be overriden with the `doc-valid-idents` configuration parameter as noted by the [documentation](https://rust-lang.github.io/rust-clippy/master/index.html#/doc_markdown), but I believe the word "DevOps" is sufficiently common to belong alongside exceptions like "GitHub" and "GitLab".
changelog: [`doc_markdown`]: Fix DevOps false positive.
rustdoc: use current stage if download-rustc enabled
When using download-rustc, using stage 1 rustdoc results in the wrong librustc_driver being used.
```sh
$ ./build/host/stage1/bin/rustdoc --version
./build/host/stage1/bin/rustdoc: error while loading shared libraries: librustc_driver-7ff02ed05016d515.so: cannot open shared object file: No such file or directory
```
This change fixes that by not cutting the stage if download-rustc is enabled.
