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

Simplify higher-ranked LUB/GLB #45853

Merged
merged 4 commits into from
Nov 18, 2017

Conversation

nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Nov 7, 2017

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

@nikomatsakis nikomatsakis force-pushed the chalk-simplify-hr-lub-glb branch from 0948c82 to 77ca1b7 Compare November 7, 2017 22:44
@Mark-Simulacrum Mark-Simulacrum added the relnotes Marks issues that should be documented in the release notes of the next release. label Nov 7, 2017
@kennytm kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 8, 2017
@nikomatsakis nikomatsakis force-pushed the chalk-simplify-hr-lub-glb branch from c924176 to e782f33 Compare November 8, 2017 09:20
@arielb1
Copy link
Contributor

arielb1 commented Nov 8, 2017

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
Copy link
Contributor

arielb1 commented Nov 8, 2017

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

@arielb1
Copy link
Contributor

arielb1 commented Nov 8, 2017

@bors r+

@bors
Copy link
Contributor

bors commented Nov 8, 2017

📌 Commit e782f33 has been approved by arielb1

@kennytm kennytm 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 Nov 10, 2017
@bors
Copy link
Contributor

bors commented Nov 12, 2017

⌛ Testing commit e782f33137258d27566d2217f6e068c2ff24d3c0 with merge 827619703a023bb5e57d6450979a91040aca1f61...

@bors
Copy link
Contributor

bors commented Nov 12, 2017

💔 Test failed - status-appveyor

@kennytm
Copy link
Member

kennytm commented Nov 12, 2017

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
Copy link
Contributor Author

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
Copy link
Contributor

arielb1 commented Nov 12, 2017

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

@nikomatsakis nikomatsakis force-pushed the chalk-simplify-hr-lub-glb branch 2 times, most recently from e782f33 to 0bbbfaf Compare November 13, 2017 10:28
@nikomatsakis
Copy link
Contributor Author

@bors r=arielb1

@bors
Copy link
Contributor

bors commented Nov 13, 2017

📌 Commit 0bbbfaf has been approved by arielb1

@bors
Copy link
Contributor

bors commented Nov 13, 2017

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

@bors
Copy link
Contributor

bors commented Nov 13, 2017

💔 Test failed - status-travis

@kennytm
Copy link
Member

kennytm commented Nov 13, 2017

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.

@kennytm kennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 13, 2017
@nikomatsakis
Copy link
Contributor Author

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

@kennytm
Copy link
Member

kennytm commented Nov 14, 2017

@nikomatsakis Looks like Travis passed this time.

@nikomatsakis nikomatsakis force-pushed the chalk-simplify-hr-lub-glb branch from 7985ac6 to bb0e756 Compare November 14, 2017 09:51
@kennytm kennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 14, 2017
@nikomatsakis
Copy link
Contributor Author

Huh. Interesting.

self.check_and_note_conflicting_crates(diag, terr, span);
self.tcx.note_and_explain_type_err(diag, terr, span);
self.check_and_note_conflicting_crates(diag, terr, span);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

duplicate call to check_and_note_conflicting_crates?

@nikomatsakis
Copy link
Contributor Author

@arielb1 argh

@nikomatsakis nikomatsakis force-pushed the chalk-simplify-hr-lub-glb branch from bd9167e to 5e9469c Compare November 16, 2017 16:43
@nikomatsakis
Copy link
Contributor Author

Fixed, added more comments.

@nikomatsakis
Copy link
Contributor Author

@bors r=arielb1

@bors
Copy link
Contributor

bors commented Nov 16, 2017

📌 Commit 5e9469c has been approved by arielb1

@nikomatsakis
Copy link
Contributor Author

@bors r-

@arielb1
Copy link
Contributor

arielb1 commented Nov 16, 2017

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

@nikomatsakis
Copy link
Contributor Author

Agreed. Waiting for #45825 to land.

@bors
Copy link
Contributor

bors commented Nov 16, 2017

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

@nikomatsakis nikomatsakis force-pushed the chalk-simplify-hr-lub-glb branch from 5e9469c to 9877fa0 Compare November 17, 2017 15:33
@nikomatsakis
Copy link
Contributor Author

@bors r=arielb1

@bors
Copy link
Contributor

bors commented Nov 17, 2017

📌 Commit 9877fa0 has been approved by arielb1

@kennytm kennytm 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 17, 2017
@bors
Copy link
Contributor

bors commented Nov 17, 2017

⌛ Testing commit 9877fa0 with merge c86d99d...

bors added a commit that referenced this pull request Nov 17, 2017
Simplify higher-ranked LUB/GLB

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
@bors
Copy link
Contributor

bors commented Nov 17, 2017

💔 Test failed - status-appveyor

@kennytm
Copy link
Member

kennytm commented Nov 17, 2017

@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
Copy link
Contributor

bors commented Nov 17, 2017

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

bors added a commit that referenced this pull request Nov 17, 2017
Simplify higher-ranked LUB/GLB

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
@bors
Copy link
Contributor

bors commented Nov 18, 2017

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

@bors bors merged commit 9877fa0 into rust-lang:master Nov 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants