-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Short-cut T: Sized
trait selection for ADTs
#33138
Conversation
span_bug!( | ||
obligation.cause.span, | ||
"builtin bound for {:?} was ambig", | ||
"confiriming builtin impl for {:?} where none exists", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: s/confiriming/confirming/
I rationalized the WF behaviour for tuples - this needs a crater run. |
crater run launched |
Crater run failed because building this branch failed: https://tools.taskcluster.net/task-inspector/#eqYUkXetSja7miFf4nXmeQ/0 |
/// such. | ||
/// - a TyError, if a type contained itself. The representability | ||
/// check should catch this case. | ||
fn calculate_sized_constraint_inner(&'tcx self, tcx: &ty::TyCtxt<'tcx>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Total nit: I personally prefer the "main method" to be listed first, and the auxiliary helper methods to be listed below it. I find it easier to read (and indeed I was confused reading this patch for a bit, since the "flow" of code was interrupted by helper fns.) But feel free to ignore me if you would rather keep the current ordering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just rewrote this code about half-a-dozen times.
// - proving `Vec<M>: Front` requires | ||
// - `M: Sized` <-- cycle! | ||
// | ||
// If we skip the normalization step, though, everything goes fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add to this comment to say:
"One fix would be lazy normalization. At the moment, we do still eagerly normalize, but we still skip the normalization step because, in PR #33138, we only consider the last field of Vec
, which is a usize
."
@arielb1 this is a beautiful patch. I would r+ it, except that I think it violates my proposed stability policy. I think we ought to be making an effort to either issue warnings or at least issue targeted errors regarding the new changes. Moreover, this seems to be a case where we could readily do so. I am happy to write up the "breaking change issue description" if you like. In any case, you should fix the branch so we can do a crater run and test things. |
Are you talking about the tuple: Sized issue? I don't feel like introducing RFC1214 obligations again. But maybe we need such a framework in general for handling warnings? |
@arielb1 I am talking about the |
Failing that, we could issue an error, but at least direct people to some place that explains the fix. That may be sufficient, and doesn't require as much precision, since it's ok to direct people unnecessarily. |
(I'd like to see the crater impact; if it is zero or very minimal, issuing an error and trying to direct people is probably adequate.) |
Reporting a warning would put us in caching hell. I will improve the error message. |
@arielb1 ok, but let's get the crater run going too. |
Done. |
@arielb1 crater run started |
Crater run results: https://gist.github.com/nikomatsakis/abb0ed492d3cb785af858b87ad3b95fd
I've not investigated these at all. |
|
Tricky. It seems like we can pull that change to tuples out into a distinct PR, and introduce as a warning first -- it may be that we can write some a kind of "warning post-pass" that checks all tuples types that occur in trait methods and issues warnings. This wouldn't cover all possible cases, but hopefully it would hit those that occur in practice (I think they are mostly tied to default methods?). Breaking 34 crates without a warning period seems ungood. cc @rust-lang/core |
The problem is that allowing tuples with unsized elements to be sized is too much of a footgun. I guess I should just disallow that. |
@nikomatsakis Fixing rayon cleans up a majority of that list, so it's not so bad. ndarray has been fixed with 0.5.1. |
this commit should be reverted after a release cycle
rebased |
FutureIncompatibleInfo { | ||
id: LintId::of(UNSIZED_IN_TUPLE), | ||
reference: "RFC PR 1592 <https://github.com/rust-lang/rfcs/pull/1592>", | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add info for OBJECT_UNSAFE_FRAGMENT
too?
Also, can you point this at the summary issue that I see you are drafting? (#33242)
@bors r+ |
📌 Commit 2d0fcc9 has been approved by |
@bors r=nikomatsakis |
📌 Commit ef581db has been approved by |
@bors r=nikomatsakis |
📌 Commit 238e4ee has been approved by |
Short-cut `T: Sized` trait selection for ADTs Basically avoids all nested obligations when checking whether an ADT is sized - this speeds up typeck by ~15% The refactoring fixed #32963, but I also want to make `Copy` not object-safe (will commit that soon). Fixes #33201 r? @nikomatsakis
Basically avoids all nested obligations when checking whether an ADT is sized - this speeds up typeck by ~15%
The refactoring fixed #32963, but I also want to make
Copy
not object-safe (will commit that soon).Fixes #33201
r? @nikomatsakis