Tracking issue for unsized types within tuples #33242
Labels
B-unstable
Blocker: Implemented in the nightly compiler and unstable.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
This is the summary issue for the
UNSIZED_IN_TUPLE
future-compatibility warning and other related errors. The goal of
this page is describe why this change was made and how you can fix
code that is affected by it. It also provides a place to ask questions
or register a complaint if you feel the change should not be made. For
more information on the policy around future-compatibility warnings,
see our breaking change policy guidelines.
What is the warning for?
Among other things, Rust's WF rules guarantee that every type in a legal program is representable. For ADTs, this means that the offsets to every field in the ADT must be known, which requires for every field but the last to be
Sized
.Because tuples are just anonymous ADTs, this requirement also holds for them. However, that requirement was missing from RFC 1214 and the original implementation. This error was found during the work for PR #33138, and this deficiency is to be fixed in rustc 1.10.
As these ill-formed tuples result in an ICE when used, this affects user code mostly in trait declarations. An example from the standard library is the (unstable) trait
core::num::bignum::FullOps
:Here the function
full_mul
returns a(Self, Self)
tuple, which is only well-formed when theSelf
-type isSized
- for that and other reasons, the trait only makes sense whenSelf
isSized
. The solution in this case and most others is to add the missingSized
supertrait.Note: at this moment, due to issue #33241, the old
trans
code crashes when translating code that uses unsized tuples even if only the last field is unsized. This should be fixed for MIR trans and should not imply in any way that these tuples are ill-formed.When will this warning become a hard error?
At the beginning of each 6-week release cycle, the Rust compiler team
will review the set of outstanding future compatibility warnings and
nominate some of them for Final Comment Period. Toward the end of
the cycle, we will review any comments and make a final determination
whether to convert the warning into a hard error or remove it
entirely.
The text was updated successfully, but these errors were encountered: