Autoharness: model caller-controlled aliasing between reference/pointer arguments

[feliperodri]

Follow-up from #4691 (see this review thread). Towards #3832.

Summary

Autoharness generates every reference, pointer, slice, and string argument from its own independent nondeterministic storage. As a result, it does not explore aliasing between distinct arguments — two &T arguments always point to separate allocations and can never share an address. A successful automatic harness is therefore an underapproximation with respect to caller-controlled aliasing (analogous to the single-monomorphization underapproximation for generic functions).

This is pre-existing behavior for all reference/pointer arguments (not specific to the &[T]/&str support added in #4691). #4691 documents it as a known limitation (docs/src/reference/experimental/autoharness.md, "Reference and Pointer Arguments" section); this issue tracks actually modeling the aliasing choices.

Example

fn f(a: &[u8], b: &[u8]) {
    assert!(!core::ptr::eq(a, b));
}

A real caller may pass the same slice twice (f(s, s)), making the assertion fail. The generated harness always uses distinct backing arrays, so core::ptr::eq(a, b) is always false and the harness reports success. The same holds for the simpler fn f(a: &u8, b: &u8).

Proposal

Explore modeling aliasing configurations across shared-reference arguments so that autoharness covers the cases where a caller passes aliasing (or equal) references, rather than only the all-distinct configuration. Points to consider:

• Which aliasing relationships to enumerate (e.g. nondeterministically choosing, for each compatible pair of arguments, whether they alias) and how that interacts with mutability (&mut aliasing is UB and must not be introduced).
• Overlap/partial aliasing for slices (sub-slice relationships), not just full pointer equality.
• Cost: aliasing choices multiply the state space, so this likely needs to be bounded/opt-in.

Until this is addressed, the documented limitation stands.