Repository navigation
rustlantis: validate projection chains when constructing places #1160
Description
Problem
mir::syntax::Place currently accepts projection chains without validating them when they are constructed.
Both Place::from_projected and Place::project can therefore create a Place containing an invalid sequence of ProjectionElems. Invalid projections can remain unchecked until Place::ty()
calls TyId::projected_ty(), which may panic while interpreting the chain.
This delays detection of malformed MIR state and makes the source of the invalid projection harder to identify.
Proposed change
Validate each projection as it is appended to a Place.
Projection validation should cover:
- dereferencing only pointer/reference types
- tuple field bounds
- struct field bounds
- array projection source types and constant-index bounds
- enum downcast variant and field bounds
- consistency between the type stored in
DowncastFieldand the actual field type
The projection type semantics should remain centralized rather than duplicating the ProjectionElem matching logic between construction and later type lookup.
Expected behavior
After this change, invalid projection chains should fail at the point where the Place is constructed or extended, rather than later during Place::ty().
Existing valid projection paths generated by Rustlantis should continue to behave unchanged.
Activity
nihalpasham commentedon Aug 24, 2026
This needs a narrower, evidence-backed problem statement before we schedule it.
Place::from_projectedandPlace::projectare unchecked, but we have not found a production caller that creates an invalid chain. Please provide a minimal generated seed or caller that fails today.LocalDecls; a caller-supplied base type is not enough.Indexmust also reject a missing or non-usizelocal.Without a reachable failure, please frame this as defensive hardening and explain its concrete maintenance value. This follows the current acceptance criteria.
nihalpasham commentedon Sep 18, 2026
I reviewed #1263 as defensive hardening. Place construction now checks projections against the authoritative local declarations, including rejecting an
i32index local whereusizeis required.The valid-chain controls and seed comparisons pass. This catches malformed generator state before it can be mistaken for a backend failure; I am not claiming a reachable old seed failure. The PR depends on #1262's generator build fix; hosted CI passes on both reviewed heads.
This covers the agreed defensive scope and closes this issue once merged.