I don't think we have thoroughly tested the cast logic and we should probably revisit some assertions as well as the code structure in general. Issues I noticed while working on #1522:
- Incorrect code path. E.g.: casting
std::boxed::Box<dyn Byte + std::marker::Sync> to std::boxed::Box<dyn Byte> was invoking cast_sized_expr_to_unsized_expr.
- Incorrect assumptions / misleading names: E.g.:
- Functions like
cast_sized_pointer_to_fat_pointer and cast_sized_expr_to_unsized_expr operates under the assumption that we are casting sized to unsized, but at the same time they start checking if the type of source is the same type as destination.
- Function
cast_sized_expr_to_unsized_expr is not necessarily casting a sized expression to an unsized expression. A big part of it does thin pointer to fat pointer conversion. Both generate pointers which are sized expressions.
- Trivially true assertions and (hopefully) unreachable code paths. E.g.:
Note: I renamed cast_sized_expr_to_unsized_expr to cast_expr_to_unsized_expr in #1522 to alleviate the first inconsistency, but it is still incorrect.
FYI: the issues we've seen so far trigger internal compiler errors (e.g.: #1528).
I don't think we have thoroughly tested the cast logic and we should probably revisit some assertions as well as the code structure in general. Issues I noticed while working on #1522:
std::boxed::Box<dyn Byte + std::marker::Sync>tostd::boxed::Box<dyn Byte>was invokingcast_sized_expr_to_unsized_expr.cast_sized_pointer_to_fat_pointerandcast_sized_expr_to_unsized_exproperates under the assumption that we are casting sized to unsized, but at the same time they start checking if the type of source is the same type as destination.cast_sized_expr_to_unsized_expris not necessarily casting a sized expression to an unsized expression. A big part of it does thin pointer to fat pointer conversion. Both generate pointers which are sized expressions.Note: I renamed
cast_sized_expr_to_unsized_exprtocast_expr_to_unsized_exprin #1522 to alleviate the first inconsistency, but it is still incorrect.FYI: the issues we've seen so far trigger internal compiler errors (e.g.: #1528).