feat(rt): handle zero-sized locals #809
Conversation
|
Related: #675 |
| // Fallback for zero-sized constants whose type metadata was not emitted. | ||
| rule <k> operandConstant(constOperand(_, _, mirConst(constantKindZeroSized, TY, _))) | ||
| => Aggregate(variantIdx(0), .List) | ||
| ... | ||
| </k> | ||
| requires typeInfoVoidType ==K lookupTy(TY) |
There was a problem hiding this comment.
Do we actually see this case? (no metadata available)
We have rules for ZeroSized constants with known metadata so if we find this necessary we should investigate it more.
There was a problem hiding this comment.
- This is needed by passing the
interior-mut*functions in feat: model interior borrows for refcell #786 - But yes, I can move this rule to another pr to investigate more.
There was a problem hiding this comment.
| // Borrowing a zero-sized local that is still `NewLocal`: initialise it, then reuse the regular rule. | ||
| rule <k> rvalueRef(REGION, KIND, place(local(I), PROJS)) | ||
| => #forceSetLocal(local(I), Aggregate(variantIdx(0), .List)) | ||
| ~> rvalueRef(REGION, KIND, place(local(I), PROJS)) | ||
| ... | ||
| </k> | ||
| <locals> LOCALS </locals> | ||
| requires 0 <=Int I andBool I <Int size(LOCALS) | ||
| andBool isNewLocal(LOCALS[I]) | ||
| andBool #zeroSizedType(lookupTy(tyOfLocal(getLocal(LOCALS, I)))) | ||
| [preserves-definedness] // valid list indexing checked, zero-sized locals materialise trivially | ||
There was a problem hiding this comment.
These are very useful rules to handle the cases described in #675 .
Maybe we could call #decodeConstant instead of assuming an Aggregate and inserting it directly?
Stevengre
changed the title
| if not component_tys: | ||
| if data: | ||
| raise ValueError(f'Zero-sized tuple expected empty data, got: {data!r}') | ||
| return AggregateValue(0, []) | ||
|
|
||
| raise ValueError('Tuple decoding with components is not implemented yet') |
There was a problem hiding this comment.
Can you please create an issue to add tuple decoding?
It depends on how the layout is, maybe we can just decode the components in sequence? Or can the fields be out of order for tuples?
There was a problem hiding this comment.
Here are the issues:
No description provided.