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 object-unsafe non-principal fragments #33243

Closed
arielb1 opened this issue Apr 27, 2016 · 1 comment
Closed

Tracking issue for object-unsafe non-principal fragments #33243

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

Comments

@arielb1
Copy link
Contributor

arielb1 commented Apr 27, 2016

This is the summary issue for the OBJECT_UNSAFE_FRAGMENT
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?

Trait object types (for example fmt::Debug + Send + 'a) are defined as a set of bounds, called
fragments. For soundness, all trait fragments are required to be object-safe.

The current implementation of rustc implements object types as being comprised of a principal trait and a set of non-principal fragments. Versions of rustc prior to 1.10 did not check that the traits in the non-principal fragments are safe. This was fixed in PR #33138. As a result, types like Error + Sized were allowed, causing confusion and ICEs.

As these types do not make much sense, they must not be used. Removing the offending fragment should generally fix the problem.

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-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. Same applies to #33242, so for now let's discuss there (though it's conceivable that the impact is different).

@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.
Projects
None yet
Development

No branches or pull requests

2 participants