Short-cut T: Sized trait selection for ADTs

[arielb1]

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

[jonas-schievink]

nit: s/confiriming/confirming/

[arielb1]

I rationalized the WF behaviour for tuples - this needs a crater run.

[nikomatsakis]

crater run launched

[nikomatsakis]

Crater run failed because building this branch failed: https://tools.taskcluster.net/task-inspector/#eqYUkXetSja7miFf4nXmeQ/0

[nikomatsakis]

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.

[arielb1]

I just rewrote this code about half-a-dozen times.

[nikomatsakis]

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."

[nikomatsakis]

@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.

[arielb1]

@nikomatsakis

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?

[nikomatsakis]

@arielb1 I am talking about the Copy and Sized trait object-safety change but also the tuple: Sized issue, yeah. It seems like we have a specific obligation cause for "tuple-sized" requirements -- we should be able to just issue a warning in that case, no?

[nikomatsakis]

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.

[nikomatsakis]

(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.)

[arielb1]

@nikomatsakis

Reporting a warning would put us in caching hell. I will improve the error message.

[nikomatsakis]

@arielb1 ok, but let's get the crater run going too.

[arielb1]

@nikomatsakis

Done.

[nikomatsakis]

@arielb1 crater run started

[nikomatsakis]

Crater run results: https://gist.github.com/nikomatsakis/abb0ed492d3cb785af858b87ad3b95fd

• 4668 crates tested: 3047 working / 1528 broken / 35 regressed / 2 fixed / 56 unknown.

I've not investigated these at all.

[jonas-schievink]

• shapir is using Box<Error + Sized>
• All other root regressions are due to trait methods returning Self in a tuple without a Self: Sized bound (I think)

[nikomatsakis]

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

[arielb1]

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.

[bluss]

@nikomatsakis Fixing rayon cleans up a majority of that list, so it's not so bad. ndarray has been fixed with 0.5.1.

[arielb1]

rebased

[nikomatsakis]

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)

[nikomatsakis]

@bors r+

[bors]

📌 Commit 2d0fcc9 has been approved by nikomatsakis

[arielb1]

@bors r=nikomatsakis

[bors]

📌 Commit ef581db has been approved by nikomatsakis

[arielb1]

@bors r=nikomatsakis

[bors]

📌 Commit 238e4ee has been approved by nikomatsakis

[bors]

⌛ Testing commit 238e4ee with merge 5158f3b...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-32cross-opt, auto-linux-64-cargotest, auto-linux-64-cross-armhf, auto-linux-64-cross-armsf, auto-linux-64-cross-freebsd, auto-linux-64-cross-netbsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-cross-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild