Simplify higher-ranked LUB/GLB

[nikomatsakis]

This is a better version of #44211. It still makes higher-ranked LUB/GLB into a hard equality test, however, it does try to identify that something changed and issue a notice to the user. I wroteup #45852 as a tracking issue for this change.

Currently, this moves straight to a hard-error, on the basis that the crater run in #44211 saw no impact. It might be good to retest -- or perhaps to try for a warning period. Trying to do the latter in a precise way would be somewhat painful, but an imprecise way might suffice -- that is, we could issue warning whenever a LUB/GLB operation succeeds that will later fail, even if it doesn't ultimately impact the type check. I could experiment with this.

I am mildly wary about landing this independently of other code that moves to a universe-based system. In particular, I was nervous that this change would make coherence accepts new pairs of impls that will later be errors. I have the code for the universe-based approach available, I hope to open an PR and run some tests on its impact very shortly. @arielb1 points out that I was being silly.

r? @arielb1

[arielb1]

In particular, I was nervous that this change would make coherence accepts new pairs of impls that will later be errors

Coherence is based only on type equality, while this PR only affects subtyping - I don't believe the LUB code can be run from coherence.

[arielb1]

if that wasn't clear, r=me unless there's some other complication about coherence.

[arielb1]

@bors r+

[bors]

📌 Commit e782f33 has been approved by arielb1

[bors]

⌛ Testing commit e782f33137258d27566d2217f6e068c2ff24d3c0 with merge 827619703a023bb5e57d6450979a91040aca1f61...

[bors]

💔 Test failed - status-appveyor

[kennytm]

x86_64-windows-msvc UI test failed:

 error[E0308]: match arms have incompatible types
   --> $DIR/old-lub-glb-object.rs:20:13
    |
 20 |       let z = match 22 {
    |  _____________^
 21 | |         0 => x,
 22 | |         _ => y,
 23 | |     };
-   | |_____^ expected bound lifetime parameter 'a, found concrete lifetime
+   | |_____^ expected bound lifetime parameter 'b, found concrete lifetime
    |
    = note: expected type `&for<'a, 'b> Foo<&'a u8, &'b u8>`
               found type `&for<'a> Foo<&'a u8, &'a u8>`
    = note: this was previously accepted by the compiler but has been phased out
    = note: for more information, see https://github.com/rust-lang/rust/issues/45852
 note: match arm with an incompatible type
   --> $DIR/old-lub-glb-object.rs:22:14
    |
 22 |         _ => y,
    |              ^
 
 error: aborting due to previous error

[nikomatsakis]

Argh. I wonder if this is the same problem we saw in #44167. I'm pulling @cengizio's commits here temporarily just to see what AppVeyor says.

[arielb1]

I think we should wait for his PR to land and then rebase this one on top of it

[nikomatsakis]

@bors r=arielb1

[bors]

📌 Commit 0bbbfaf has been approved by arielb1

[bors]

⌛ Testing commit 0bbbfaf with merge 55324a9a5b7b2a7eaa7bae4c8ffb4c1967f16de1...

[bors]

💔 Test failed - status-travis

[kennytm]

armhf-gnu, exactly the same error as before.

 error[E0308]: match arms have incompatible types
   --> $DIR/old-lub-glb-object.rs:20:13
    |
 20 |       let z = match 22 {
    |  _____________^
 21 | |         0 => x,
 22 | |         _ => y,
 23 | |     };
-   | |_____^ expected bound lifetime parameter 'a, found concrete lifetime
+   | |_____^ expected bound lifetime parameter 'b, found concrete lifetime
    |
    = note: expected type `&for<'a, 'b> Foo<&'a u8, &'b u8>`
               found type `&for<'a> Foo<&'a u8, &'a u8>`
    = note: this was previously accepted by the compiler but has been phased out
    = note: for more information, see https://github.com/rust-lang/rust/issues/45852
 note: match arm with an incompatible type
   --> $DIR/old-lub-glb-object.rs:22:14
    |
 22 |         _ => y,
    |              ^
 
 error: aborting due to previous error

Edit: x86_64-pc-windows-msvc also produces the same error like before.

[nikomatsakis]

@kennytm thanks, I'll take a look more closely then. Thought we had squelched that.

[kennytm]

@nikomatsakis Looks like Travis passed this time.

[nikomatsakis]

Huh. Interesting.

[arielb1]

duplicate call to check_and_note_conflicting_crates?

[nikomatsakis]

@arielb1 argh

[nikomatsakis]

Fixed, added more comments.

[nikomatsakis]

@bors r=arielb1

[bors]

📌 Commit 5e9469c has been approved by arielb1

[nikomatsakis]

@bors r-

[arielb1]

I think it's a good idea to have #45825 land first

[nikomatsakis]

Agreed. Waiting for #45825 to land.

[bors]

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

[nikomatsakis]

@bors r=arielb1

[bors]

📌 Commit 9877fa0 has been approved by arielb1

[bors]

⌛ Testing commit 9877fa0 with merge c86d99d...

[bors]

💔 Test failed - status-appveyor

[kennytm]

@bors retry

check i686-pc-windows-msvc 3-hour timeout

Time breakdown

step	1.0.5329	1.0.5390
make prepare	51.32	56.5
stage0-std	46.15	73.53
stage0-tidy	7.99	9.69
bootstrap	17.54	25.72
stage0-test	15.39	16.74
llvm	448.4	693.57
stage0-rustc	1034.28	1133.1
stage1-std	57.4	66.13
stage1-test	20.3	24.27
stage1-rustc	1489.61	1702.34
stage0-compiletest	64.62	86.1
test/ui	32.7	60.9
test/run-pass	1373.26	2526.66
test/compile-fail	313.2	395.92
test/parse-fail	5.65	6.77
test/run-fail	28.51	60.63
test/run-pass-valgrind	3.8	3.77
test/mir-opt	13.58	37.95
test/codegen	6.26	11.35
test/codegen-units	7.19	11.74
test/incremental	66.69	74.59
test/ui-fulldeps	15.18	15.05
test/run-pass-fulldeps	219.09	242.29
test/run-fail-fulldeps	3.99	4.96
test/compile-fail-fulldeps	62.53	77
stage2-rustdoc	266.1	290.77
test/run-make	93.56	137.75
test/rustdoc	109.51	130.62
stage1-std(test)	190.87	264.18
test/libstd	807.12	1283.24
stage1-test(test)	16.5	16.8
test/libtest	17.41	17.85
stage1-rustc(test)	341.36	336.32
test/librustc	345.77	345.37
stage2-rustdoc(test)	29.8	41.15
test/librustdoc	30.37	48.84
stage0-unstable-book-gen	11.15	19.6
stage0-rustbook	241.87	203.27
doc/libstd	24.7	42.79
doc/libproc_macro	1.39	3.44
stage0-error_index_gen	5.67	7.12
stage0-linkchecker	3.2	3.23
test/linkchecker	35.87	37.21
doc tests	261.95
error-index tests	61.61

Everything, even LLVM build went slower than usual. I think it's just AppVeyor's problem.

[bors]

⌛ Testing commit 9877fa0 with merge 18d8acf...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: arielb1
Pushing 18d8acf to master...