compiletest: Document various parts of compiletest's `lib.rs`
This adds some much-needed comments to many of the items in compiletest's `lib.rs`, giving a better overview of how a compiletest invocation actually proceeds.
To make review easier I have refrained from renames or functional changes, though I couldn't resist getting rid of one obviously-redundant `Arc::clone` in `make_test_closure`.
Special treatment empty tuple when suggest adding a string literal in format macro.
For example:
```rust
let s = "123";
println!({}, "sss", s);
```
Suggest:
`println!("{:?} {} {}", {}, "sss", s);`
fixes#130170
Update precondition tests (especially for zero-size access to null)
I don't much like the current way I've updated the precondition check helpers, but I couldn't come up with anything better. Ideas welcome.
I've organized `tests/ui/precondition-checks` mostly with one file per function that has `assert_unsafe_precondition` in it, with revisions that check each precondition. The important new test is `tests/ui/precondition-checks/zero-size-null.rs`.
Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly
Currently `clobber_abi` in Arm64EC inline assembly is implemented using `InlineAsmClobberAbi::AArch64NoX18`, but broken since it attempts to clobber registers that cannot be used in Arm64EC: https://godbolt.org/z/r3PTrGz5r
```
error: cannot use register `x13`: x13, x14, x23, x24, x28, v16-v31 cannot be used for Arm64EC
--> <source>:6:14
|
6 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x14`: x13, x14, x23, x24, x28, v16-v31 cannot be used for Arm64EC
--> <source>:6:14
|
6 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
<omitted the same errors for v16-v31>
```
Additionally, this disallows SVE-related registers per https://github.com/rust-lang/rust/pull/131332#issuecomment-2401189142.
cc ``@dpaoliello``
r? ``@Amanieu``
``@rustbot`` label O-windows O-AArch64 +A-inline-assembly
Stabilize `Pin::as_deref_mut()`
Tracking issue: closes#86918
Stabilizing the following API:
```rust
impl<Ptr: DerefMut> Pin<Ptr> {
pub fn as_deref_mut(self: Pin<&mut Pin<Ptr>>) -> Pin<&mut Ptr::Target>;
}
```
I know that an FCP has not been started yet, but this isn't a very complex stabilization, and I'm hoping this can motivate an FCP to *get* started - this has been pending for a while and it's a very useful function when writing Future impls.
r? ``@jonhoo``
chore: rename `salsa` to `ra_salsa`
Laying some groundwork to start before I import the new Salsa crate. Here's why:
1. As part of the migration, `@darichey,` `@Wilfred,` and I will create new Salsa equivalents of the existing databases/query groups. We'll get them to compile crate-by-crate.
2. Once we wrote all equivalents of all queries, we'd start to refactor usage sites of the vendored Salsa to use the new Salsa databases.
3. Starting porting usage sites of old Salsa to the new Salsa.
4. Remove the vendored `ra_salsa`; declare victory.
internal: switch remaining OpQueues to use named structs
Building atop of https://github.com/rust-lang/rust-analyzer/pull/18195, I switched `GlobalState::fetch_build_data_queue` to use a struct instead of a tuple.
(I didn't switch `fetch_proc_macros_queue` to not return a bool, as the return value is only used in one spot.)
feat: respect references.exclude_tests in call-hierarchy
close#18212
### Changes
1. feat: respect `references.exclude_tests` in call-hierarchy
2. Modified the description of `references.exclude_tests`
fix: Do not consider mutable usage of deref to `*mut T` as deref_mut
Fixes#15799
We are doing some heuristics for deciding whether the given deref is deref or deref_mut here;
5982d9c420/crates/hir-ty/src/infer/mutability.rs (L182-L200)
But this heuristic is erroneous if we are dereferencing to a mut ptr and normally those cases are filtered out here as builtin;
5982d9c420/crates/hir-ty/src/mir/lower/as_place.rs (L165-L177)
Howerver, this works not so well if the given dereferencing is double dereferencings like the case in the #15799.
```rust
struct WrapPtr(*mut u32);
impl core::ops::Deref for WrapPtr {
type Target = *mut u32;
fn deref(&self) -> &Self::Target {
&self.0
}
}
fn main() {
let mut x = 0u32;
let wrap = WrapPtr(&mut x);
unsafe {
**wrap = 6;
}
}
```
Here are two - outer and inner - dereferences here, and the outer dereference is marked as deref_mut because there is an assignment operation.
And this deref_mut marking is propagated into the inner dereferencing.
In the later MIR lowering, the outer dereference is filtered out as it's expr type is `*mut u32`, but the expr type in the inner dereference is an ADT, so this false-mutablility is not filtered out.
This PR cuts propagation of this false mutablilty chain if the expr type is mut ptr.
Since this happens before the resolve_all, it may have some limitations when the expr type is determined as mut ptr at the very end of inferencing, but I couldn't find simple fix for it 🤔
This special case in `output_base_dir` had the unfortunate side-effect of
causing all run-make tests to share the same `stamp` file. So as soon as any
one of them succeeded, all of the failed tests would be considered up-to-date
and would no longer run in subsequent test invocations.
internal: Don't resolve extern crates in import fix point resolution
The fix point loop won't progress them given the potential extern crate candidates are set up at build time.
fix: Join rustfmt overrideCommand with project root
When providing a custom rustfmt command, join it with the project root instead of the workspace root. This fixes rust-analyzer getting the wrong invocation path in projects containing subprojects.
This makes the behaviour consistent with how a custom path provided in rust-analyzer.procMacro.server behaves already.
Resolves issue #18222
feat: Highlight exit points of async blocks
Async blocks act similar to async functions in that the await keywords are related, but also act like functions where the exit points are related.
Fixes#18147
`GenKillAnalysis` has very similar methods to `Analysis`, but the first
two have a notable difference: the second argument is `&mut impl
GenKill<Self::Idx>` instead of `&mut Self::Domain`. But thanks to the
previous commit, this difference is no longer necessary.
This is an alternative to `Engine::new_generic` for gen/kill analyses.
It's supposed to be an optimization, but it has negligible effect.
The commit merges `Engine::new_generic` into `Engine::new`.
This allows the removal of various other things: `GenKillSet`,
`gen_kill_statement_effects_in_block`, `is_cfg_cyclic`.
- Using EFI Shell Protocol. These functions do not make much sense
unless a shell is present.
- Return the exe dir in case shell protocol is missing.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Also use outermost const-anon for impl items in `non_local_defs` lint
This PR update the logic for the impl paths (items) in the `non_local_definitions` lint to also consider const-anon in case the impl definition is wrapped inside const-anon it-self wrapped into a const-anon where the items are.
r? `@jieyouxu` *(since you interacted on the issue)*
Fixes *(after beta-backport)* #131643
merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate
https://github.com/rust-lang/rust/issues/76205 has been closed a while ago, but there are still some functions that reference it. Those functions are all unstable *and* const-unstable. There's no good reason to use a separate feature gate for their const-stability, so this PR moves their const-stability under the same gate as their regular stability, and therefore removes the remaining references to https://github.com/rust-lang/rust/issues/76205.
miri: avoid cloning AllocExtra
We shouldn't be cloning Miri allocations, so make `AllocExtra::clone` panic instead, and adjust the one case where we *do* clone (the leak check) to avoid cloning.
This is in preparation for https://github.com/rust-lang/miri/pull/3966 where I am adding something to `AllocExtra` that cannot (easily) be cloned.
r? ``@saethlin``
