Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for unsized types within tuples #33242

Closed
arielb1 opened this issue Apr 27, 2016 · 2 comments
Closed

Tracking issue for unsized types within tuples #33242

arielb1 opened this issue Apr 27, 2016 · 2 comments
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.

Comments

@arielb1
Copy link
Contributor

arielb1 commented Apr 27, 2016

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:

/// Arithmetic operations required by bignums.
pub trait FullOps {
    /// Returns `(carry', v')` such that `carry' * 2^W + v' = self + other + carry`,
    /// where `W` is the number of bits in `Self`.
    fn full_add(self, other: Self, carry: bool) -> (bool /*carry*/, Self);

    /// Returns `(carry', v')` such that `carry' * 2^W + v' = self * other + carry`,
    /// where `W` is the number of bits in `Self`.
    fn full_mul(self, other: Self, carry: Self) -> (Self /*carry*/, Self);

    /// Returns `(carry', v')` such that `carry' * 2^W + v' = self * other + other2 + carry`,
    /// where `W` is the number of bits in `Self`.
    fn full_mul_add(self, other: Self, other2: Self, carry: Self) -> (Self /*carry*/, Self);

    /// Returns `(quo, rem)` such that `borrow * 2^W + self = quo * other + rem`
    /// and `0 <= rem < other`, where `W` is the number of bits in `Self`.
    fn full_div_rem(self, other: Self, borrow: Self) -> (Self /*quotient*/, Self /*remainder*/);
}

Here the function full_mul returns a (Self, Self) tuple, which is only well-formed when the Self-type is Sized - for that and other reasons, the trait only makes sense when Self is Sized. The solution in this case and most others is to add the missing Sized 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.

@arielb1 arielb1 added T-lang Relevant to the language team, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. labels Apr 27, 2016
@nikomatsakis
Copy link
Contributor

cc @rust-lang/compiler -- @arielb1 has a PR to turn this into a hard-error (#34982). I started a crater run but am generally in favor, although it's not quite per policy (that is, it's not the start of a release cycle, etc). We don't seem to have that policy running in "full gear" though. Thoughts?

@nrc
Copy link
Member

nrc commented Jul 26, 2016

fine by me if Crater is OK

nikomatsakis added a commit to nikomatsakis/rust-comonoid that referenced this issue Aug 26, 2016
Otherwise the type `(Self, Self)` is not well-formed, as tuples may not
have unsized members. See rust-lang/rust#33242 for details.
@bors bors closed this as completed in 7b92d05 Sep 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

No branches or pull requests

3 participants