move implicit `Sized` predicate to end of list #86011

tlyu · 2021-06-04T23:04:36Z

In Bounds::predicates(), move the implicit Sized predicate to the
end of the generated list. This means that if there is an explicit
Sized bound, it will be checked first, and any resulting
diagnostics will have a more useful span.

Fixes #85998, at least partially. ~~Based on #85979, but only the last 2 commits are new for this pull request.~~ (edit: rebased) A full fix would need to deal with where-clauses, and that seems difficult. Basically, predicates are being collected in multiple stages, and there are two places where implicit Sized predicates can be inserted: once for generic parameters, and once for where-clauses. I think this insertion is happening too early, and we should actually do it only at points where we collect all of the relevant trait bounds for a type parameter.

I could use some help interpreting the changes to the stderr output. It looks like reordering the predicates changed some diagnostics that don't obviously have anything to do with Sized bounds. Possibly some error reporting code is making assumptions about ordering of predicates? The diagnostics for src/test/ui/derives/derives-span-Hash-*.rs seem to have improved, no longer pointing at the type parameter identifier, but src/test/ui/type-alias-impl-trait/generic_duplicate_param_use9.rs became less verbose for some reason.

I also ran into an instance of #84970 while working on this, but I kind of expected that could happen, because I'm reordering predicates. I can open a separate issue on that if it would be helpful.

@estebank this seems likely to conflict (slightly?) with your work on #85947; how would you like to resolve that?

rust-highfive · 2021-06-04T23:04:39Z

r? @varkor

(rust-highfive has picked a reviewer for you, use r? to override)

estebank · 2021-06-05T21:29:54Z

src/test/ui/issues/issue-16966.stderr

+   | 
+  ::: $SRC_DIR/std/src/panicking.rs:LL:COL
   |
+LL | pub fn begin_panic<M: Any + Send>(msg: M) -> ! {
+   |                       --- required by this bound in `begin_panic`
+   |
+   = note: cannot satisfy `_: Any`


This is arguably a regression.

estebank · 2021-06-05T21:36:43Z

A full fix would need to deal with where-clauses, and that seems difficult. Basically, predicates are being collected in multiple stages, and there are two places where implicit Sized predicates can be inserted: once for generic parameters, and once for where-clauses. I think this insertion is happening too early, and we should actually do it only at points where we collect all of the relevant trait bounds for a type parameter.

I made these two changes in order to have the right spans available. I'm not sure if these changes would be enough to address what you're mentioning here.

29c8a9f#diff-0a61b538a3cec072c76fecae4635af6a12ec3256860029ac70549c2aa53ab394R1480-R1485

29c8a9f#diff-ac1e6e554bac799e1e2d3886bea8fdc0d0bf04b20d33df59f5a8e92c41987ac6R2137-R2139

It looks like reordering the predicates changed some diagnostics that don't obviously have anything to do with Sized bounds. Possibly some error reporting code is making assumptions about ordering of predicates?

It some what does. I can point you at where that is happening, but if you search for where E0282 and E0284 are emitted, you'll find them. It's fine if there are small changes, we just might have to tweak the logic there to keep whatever checks we currently have.

src/test/ui/type-alias-impl-trait/generic_duplicate_param_use9.rs seemed to not get more verbose, things just moved around, which make sense.

I also ran into an instance of #84970 while working on this, but I kind of expected that could happen, because I'm reordering predicates. I can open a separate issue on that if it would be helpful.

Did this happen on tests or while working on rustc? Did it happen with --keep-stage 1? If the problem is one of "we might hit this in CI" it's less concerning to me than "users will hit a new fingerprint issue in stable in 12 weeks".

estebank · 2021-06-05T21:48:12Z

r? @estebank
r=me after potentially addressing the src/test/ui/issues/issue-16966.stderr case, but if you find it difficult to do (I would just remove the note in every case where it is _: Something) or lack the time, we can land as is.

tlyu · 2021-06-06T00:45:44Z

Thanks for the review! I'll be taking a closer look at the things you pointed out and will probably reply in more detail soon.

I also ran into an instance of #84970 while working on this, but I kind of expected that could happen, because I'm reordering predicates. I can open a separate issue on that if it would be helpful.

Did this happen on tests or while working on rustc? Did it happen with --keep-stage 1? If the problem is one of "we might hit this in CI" it's less concerning to me than "users will hit a new fingerprint issue in stable in 12 weeks".

I opened issue #86013 with more details. Basically, when I either applied or reverted the patches in this PR, the fingerprints changed and I got the ICE on a specific UI test case. For what it's worth, I built the stage1 compiler and libstd using ./x.py build -i, and did not encounter ICEs while building the compiler itself.

As for whether this will cause fingerprint errors when this lands in stable? I'm not sure I know enough about the details of incremental compilation. Do we have some way of invalidating incremental compilation caches when there are internal changes to the compiler? (I hope so.) If so, how is this done? Is it part of the release process? Automatically according to the commit-hash stored during build?

tlyu · 2021-06-06T03:37:34Z

src/test/ui/type-alias-impl-trait/generic_duplicate_param_use9.rs seemed to not get more verbose, things just moved around, which make sense.

if you compare
https://github.com/rust-lang/rust/pull/86011/files#diff-06109f234a5a60a647998669551ba82a0a549f34b4741bd5da4a449afbbe14a6L13
with
https://github.com/rust-lang/rust/pull/86011/files#diff-06109f234a5a60a647998669551ba82a0a549f34b4741bd5da4a449afbbe14a6R37
you'll notice (A, B, <A as Foo>::Bar) got deleted from the error message.

For issue-16966, I found this area to be somewhat suspicious:

rust/compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs

Lines 1539 to 1543 in 6c2dd25

    
           if self.tcx.lang_items().sized_trait() == Some(trait_ref.def_id()) { 
        
               self.emit_inference_failure_err(body_id, span, subst, vec![], ErrorCode::E0282) 
        
                   .emit(); 
        
               return; 
        
           }

and I'm attempting to investigate. It maybe that the type inference ambiguity causes a bunch of simultaneous errors and we previously happened to get the Sized trait predicate first, outputting the more terse error E0282 instead of E0283.

tlyu · 2021-06-08T03:17:21Z

What I thought was the "obvious" approach to quieting the new E0283 in issue-16966 has some nontrivial fallout. Maybe the smallest change to the diagnostics is what we already have in this pull request? Do you think we need to make additional changes in this pull request?

I tried to see what would happen if I made this block in maybe_report_ambiguity() either always or never execute:

rust/compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs

Lines 1539 to 1543 in 6c2dd25

    
           if self.tcx.lang_items().sized_trait() == Some(trait_ref.def_id()) { 
        
               self.emit_inference_failure_err(body_id, span, subst, vec![], ErrorCode::E0282) 
        
                   .emit(); 
        
               return; 
        
           }

I wound up with these outputs from the UI tests:
always:
always-E0282.txt
never:
never-E0282.txt

The "never" approach generates a lot more diffs in the stderr output than the "always" approach. (51 failures with "never", vs 19 failures with "always")

A quick glance at the output from the "always" approach shows that the diffs are largely making some vague verbose diagnostics less verbose.

My guess (partially confirmed by disabling some of the verbosity suppression) is that in the case of issue-16966, the type inference ambiguity was causing every trait bound to not be satisfied, and prior to my changes, we were luckily hitting Sized first and ending up with E0282, but are now getting E0283 because the first unsatisfied bound is no longer Sized.

Any opinions on whether the deleted verbosity with "always" was at all helpful? It sounds like you might be concerned that the E0283 now appearing with issue-16966 is too verbose? If so, how do you feel about the existing instances of E0283 verbosity that are deleted in the "always" approach?

estebank · 2021-06-09T03:07:06Z

At a very quick glance, it seems like the always case removes a bunch of useful suggestions, while the never case is just more verbose and perhaps slightly misleading...

I'll try to take a look at this PR with fresh eyes tomorrow, but I think we might want to merge as is.

tlyu · 2021-06-13T18:41:57Z

@estebank

Did this happen on tests or while working on rustc? Did it happen with --keep-stage 1? If the problem is one of "we might hit this in CI" it's less concerning to me than "users will hit a new fingerprint issue in stable in 12 weeks".

I wrote an update in #86013 (comment)

It seems unlikely to affect users of released versions because invalidation of the incremental caches seems to honor changes in the commit hash.

tlyu · 2021-06-16T16:09:15Z

Opened #86371 with some discouraging findings. Maybe the better approach is to detect whether we are dealing with violating an implicit Sized bound, and adjust the span to point at any explicit Sized bound that happens to be present, instead of to the type parameter name.

bors · 2021-07-16T19:17:56Z

☔ The latest upstream changes (presumably #84623) made this pull request unmergeable. Please resolve the merge conflicts.

estebank · 2021-07-16T19:35:21Z

@tlyu can you rebase? After that r=me, but I would still like to somehow fix src/test/ui/issues/issue-16966.stderr.

tlyu · 2021-07-21T02:54:53Z

@estebank Rebase done. I looked at #16966 and the change in the stderr in this PR isn't a necessarily a regression of the substance of that issue, which is about duplication of error messages. (The change in src/test/ui/issues/issue-16966.stderr is more (potentially-useless) verbosity than there used to be, but there's no repetition.)

I think there's a big rabbit hole here of various error reporting heuristics that use the failure to satisfy the implicit Sized constraint as a way of suppressing excess verbosity. I'm not sure what to do about them, because in theory, the ordering of trait bounds should be irrelevant to type checking results, right?

bors · 2021-07-28T19:36:47Z

☔ The latest upstream changes (presumably #87540) made this pull request unmergeable. Please resolve the merge conflicts.

tlyu · 2021-07-28T23:47:03Z

Rebased again.

bors · 2021-08-03T01:58:31Z

☔ The latest upstream changes (presumably #87628) made this pull request unmergeable. Please resolve the merge conflicts.

camelid · 2021-08-20T00:17:41Z

triage: @tlyu could you rebase again? Then perhaps ping estebank to let them know the PR is ready to be approved. Thanks!

tlyu · 2021-10-08T23:54:22Z

Rebased again. A UI test is currently failing because of #89639, but I confirmed that also occurs on master.

@rustbot label -S-waiting-on-author +S-waiting-on-review

estebank · 2021-10-14T14:31:32Z

Looking at the output after the rebase, I am much more comfortable landing this as is. Apologies for the delay in landing this!

@bors r+

bors · 2021-10-14T14:31:33Z

📌 Commit c07f5c4 has been approved by estebank

…stebank move implicit `Sized` predicate to end of list In `Bounds::predicates()`, move the implicit `Sized` predicate to the end of the generated list. This means that if there is an explicit `Sized` bound, it will be checked first, and any resulting diagnostics will have a more useful span. Fixes rust-lang#85998, at least partially. ~~Based on rust-lang#85979, but only the last 2 commits are new for this pull request.~~ (edit: rebased) A full fix would need to deal with where-clauses, and that seems difficult. Basically, predicates are being collected in multiple stages, and there are two places where implicit `Sized` predicates can be inserted: once for generic parameters, and once for where-clauses. I think this insertion is happening too early, and we should actually do it only at points where we collect all of the relevant trait bounds for a type parameter. I could use some help interpreting the changes to the stderr output. It looks like reordering the predicates changed some diagnostics that don't obviously have anything to do with `Sized` bounds. Possibly some error reporting code is making assumptions about ordering of predicates? The diagnostics for src/test/ui/derives/derives-span-Hash-*.rs seem to have improved, no longer pointing at the type parameter identifier, but src/test/ui/type-alias-impl-trait/generic_duplicate_param_use9.rs became less verbose for some reason. I also ran into an instance of rust-lang#84970 while working on this, but I kind of expected that could happen, because I'm reordering predicates. I can open a separate issue on that if it would be helpful. `@estebank` this seems likely to conflict (slightly?) with your work on rust-lang#85947; how would you like to resolve that?

…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#86011 (move implicit `Sized` predicate to end of list) - rust-lang#89821 (Add a strange test for `unsafe_code` lint.) - rust-lang#89859 (add dedicated error variant for writing the discriminant of an uninhabited enum variant) - rust-lang#89870 (Suggest Box::pin when Pin::new is used instead) - rust-lang#89880 (Use non-checking TLS relocation in aarch64 asm! sym test.) - rust-lang#89885 (add long explanation for E0183) - rust-lang#89894 (Remove unused dependencies from rustc_const_eval) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

…ans, r=estebank" This reverts commit 36a1076, reversing changes made to e1e9319.

Revert rust-lang#86011 to fix an incorrect bound check This reverts commit 36a1076, reversing changes made to e1e9319. Fixes rust-lang#89935 r? `@estebank`

Revert rust-lang#86011 to fix an incorrect bound check This reverts commit 36a1076, reversing changes made to e1e9319. Fixes rust-lang#89935 r? ``@estebank``

Rollup of 10 pull requests Successful merges: - rust-lang#86479 (Automatic exponential formatting in Debug) - rust-lang#87404 (Add support for artifact size profiling) - rust-lang#87769 (Alloc features cleanup) - rust-lang#88789 (remove unnecessary bound on Zip specialization impl) - rust-lang#88860 (Deduplicate panic_fmt) - rust-lang#90009 (Make more `From` impls `const` (libcore)) - rust-lang#90018 (Fix rustdoc UI for very long type names) - rust-lang#90025 (Revert rust-lang#86011 to fix an incorrect bound check) - rust-lang#90036 (Remove border-bottom from most docblocks.) - rust-lang#90060 (Update RELEASES.md) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

…ans, r=estebank" This reverts commit 36a1076, reversing changes made to e1e9319.

…ulacrum [beta] backports * Don't emit a warning for empty rmeta files. rust-lang#90072 * Erase late-bound regions before computing vtable debuginfo name. rust-lang#90050 * Fix wrong niche calculation when 2+ niches are placed at the start rust-lang#90040 * Revert rust-lang#86011 to fix an incorrect bound check rust-lang#90025 * Fix macro_rules! duplication when reexported in the same module rust-lang#89867 * Bump cargo to include rust-lang/cargo#9979 - Fix fetching git repos after a force push. r? `@Mark-Simulacrum`

rust-highfive assigned varkor Jun 4, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 4, 2021

This comment has been minimized.

Sign in to view

tlyu mentioned this pull request Jun 4, 2021

incremental compilation error with rustc patches that change predicate order #86013

Closed

tlyu force-pushed the correct-sized-bound-spans branch 2 times, most recently from dc71393 to 6676902 Compare June 5, 2021 02:55

estebank reviewed Jun 5, 2021

View reviewed changes

rust-highfive assigned estebank and unassigned varkor Jun 5, 2021

tlyu mentioned this pull request Jun 16, 2021

[WIP] defer adding implicit Sized bounds #86371

Closed

JohnCSimon added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 5, 2021

tlyu force-pushed the correct-sized-bound-spans branch from 6676902 to 6d851c8 Compare July 20, 2021 19:52

tlyu force-pushed the correct-sized-bound-spans branch from 6d851c8 to 19f32a9 Compare July 28, 2021 23:46

tlyu force-pushed the correct-sized-bound-spans branch from 19f32a9 to c07f5c4 Compare October 8, 2021 23:51

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 8, 2021

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 14, 2021

JohnTitor mentioned this pull request Oct 15, 2021

Rollup of 8 pull requests #89901

Closed

matthiaskrgr mentioned this pull request Oct 15, 2021

Rollup of 7 pull requests #89903

Merged

bors merged commit 36a1076 into rust-lang:master Oct 15, 2021

rustbot added this to the 1.57.0 milestone Oct 15, 2021

Aaron1011 mentioned this pull request Oct 16, 2021

Rocket fails to build on latest nightly #89935

Closed

JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 18, 2021

Revert "Rollup merge of rust-lang#86011 - tlyu:correct-sized-bound-sp…

e2453dc

…ans, r=estebank" This reverts commit 36a1076, reversing changes made to e1e9319.

matthiaskrgr mentioned this pull request Oct 18, 2021

Rollup of 8 pull requests #90026

Closed

GuillaumeGomez mentioned this pull request Oct 19, 2021

Rollup of 7 pull requests #90049

Closed

ehuss mentioned this pull request Oct 19, 2021

Maybe regression in nightly when compiling cursive_core #90043

Closed

JohnTitor mentioned this pull request Oct 19, 2021

Rollup of 10 pull requests #90067

Merged

Mark-Simulacrum pushed a commit to Mark-Simulacrum/rust that referenced this pull request Oct 22, 2021

Revert "Rollup merge of rust-lang#86011 - tlyu:correct-sized-bound-sp…

e89b532

…ans, r=estebank" This reverts commit 36a1076, reversing changes made to e1e9319.

Mark-Simulacrum mentioned this pull request Oct 22, 2021

[beta] backports #90151

Merged

tlyu deleted the correct-sized-bound-spans branch November 16, 2021 04:49

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

move implicit `Sized` predicate to end of list #86011

move implicit `Sized` predicate to end of list #86011

tlyu commented Jun 4, 2021 •

edited

Loading

rust-highfive commented Jun 4, 2021

This comment has been minimized.

estebank Jun 5, 2021

estebank commented Jun 5, 2021 •

edited

Loading

estebank commented Jun 5, 2021

tlyu commented Jun 6, 2021

tlyu commented Jun 6, 2021

tlyu commented Jun 8, 2021

estebank commented Jun 9, 2021

tlyu commented Jun 13, 2021

tlyu commented Jun 16, 2021

bors commented Jul 16, 2021

estebank commented Jul 16, 2021

tlyu commented Jul 21, 2021

bors commented Jul 28, 2021

tlyu commented Jul 28, 2021

bors commented Aug 3, 2021

camelid commented Aug 20, 2021

tlyu commented Oct 8, 2021

estebank commented Oct 14, 2021

bors commented Oct 14, 2021

move implicit Sized predicate to end of list #86011

move implicit Sized predicate to end of list #86011

Conversation

tlyu commented Jun 4, 2021 • edited Loading

rust-highfive commented Jun 4, 2021

This comment has been minimized.

estebank Jun 5, 2021

Choose a reason for hiding this comment

estebank commented Jun 5, 2021 • edited Loading

estebank commented Jun 5, 2021

tlyu commented Jun 6, 2021

tlyu commented Jun 6, 2021

tlyu commented Jun 8, 2021

estebank commented Jun 9, 2021

tlyu commented Jun 13, 2021

tlyu commented Jun 16, 2021

bors commented Jul 16, 2021

estebank commented Jul 16, 2021

tlyu commented Jul 21, 2021

bors commented Jul 28, 2021

tlyu commented Jul 28, 2021

bors commented Aug 3, 2021

camelid commented Aug 20, 2021

tlyu commented Oct 8, 2021

estebank commented Oct 14, 2021

bors commented Oct 14, 2021

move implicit `Sized` predicate to end of list #86011

move implicit `Sized` predicate to end of list #86011

tlyu commented Jun 4, 2021 •

edited

Loading

estebank commented Jun 5, 2021 •

edited

Loading