Add support for accessing single-element aggregates in #traverseProjection #657
Conversation
…ction - Updated documentation to explain how to directly access elements of an Aggregate when #traverseProjection becomes stuck. - Introduced a new rule for handling single-element aggregates in the semantics. - Added a new test case for closure access to a struct, ensuring correct behavior. - Updated integration tests to include the new failure case for closure access to structs.
Stevengre
changed the title
| // Closure function that takes &MyStruct reference | ||
| let get_value = |struct_ref: &MyStruct| { | ||
| struct_ref.data | ||
| }; |
There was a problem hiding this comment.
(probably off-topic)
While reading this code, I was thinking, what if we were using the struct_list in scope (capturing the variable in the closure), like this:
let get_value = | i: usize | { struct_list[i].data }We should investigate closures a bit more (but unrelated to p-token)
| @@ -418,6 +418,19 @@ This is done without consideration of the validity of the Downcast[^downcast]. | |||
| </k> | |||
| ``` | |||
|
|
|||
| If an Aggregate contains only one element and #traverseProjection becomes stuck, you can directly access this element. For more details, you may remove this rule and run `tests/integration/data/prove-rs/closure_access_struct.rs`. | |||
There was a problem hiding this comment.
Maybe add text describing what we would see in that test when removing the rule.
Anyone who reads it will understand better without having to repeat your experiments.
| │ | ||
| │ (277 steps) | ||
| └─ 3 (stuck, leaf) | ||
| #traverseProjection ( toLocal ( 19 ) , thunk ( #decodeConstant ( constantKindAll |
There was a problem hiding this comment.
Could we write the test program in a way that avoids this constant allocation?
Maybe using a literal array of i32 and producing the struct_list via into_iter, map, and collect?
Would be nicer to have a test that terminates with the fix.
Uh oh!
There was an error while loading. Please reload this page.