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

Move self trait predicate to items #51895

Merged

Conversation

nikomatsakis
Copy link
Contributor

This is a "reimagination" of @tmandry's PR #50183. The main effect is described in this comment from one of the commits:


Before we had the following results for predicates_of:

trait Foo { // predicates_of: Self: Foo
  fn bar(); // predicates_of: Self: Foo (inherited from trait)
}

Now we have removed the Self: Foo from the trait. However, we still
add it to the trait ITEM. This is because when people do things like
<T as Foo>::bar(), they still need to prove that T: Foo, and
having it in the predicates_of seems to be the cleanest way to
ensure that happens right now (otherwise, we'd need special case code
in various places):

trait Foo { // predicates_of: []
  fn bar(); // predicates_of: Self: Foo
}

However, we sometimes want to get the list of just the predicates
truly defined on a trait item (e.g., for chalk, but also for a few
other bits of code). For that, we define predicates_defined_on,
which does not contain the Self: Foo predicate yet, and we plumb
that through metadata and so forth.


I'm assigning @eddyb as the main reviewer, but I thought I might delegate to scalexm for this one in any case. I also want to post an alternative that I'll leave in the comments; it occurred to me as I was writing. =)

r? @eddyb
cc @scalexm @tmandry @leodasvacas

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 29, 2018
@nikomatsakis
Copy link
Contributor Author

It occurs to me that a less disruptive way to achieve the main goal of this PR would be to

  • create predicates_defined_on vs predicates_of
  • continue to add the Self: Trait predicate but for traits, not trait items

(We would have to rework slightly how the instantiate mechanism works, since we would want to instantiate the predicates_defined_on of the parent -- I realize now that this is always instantiating predicates_of of the parent, but that's ok at the moment.)

Crucially, this would still mean that the rest of the compiler thinks that Foo: Trait being WF requires Foo: Trait to hold. This would also mean we don't have to modify ParamEnv. Those things mean less "churn" -- but they are not necessarily good. After all, the WF requirement is just overly zealous.

For background, I think that the way that @scalexm and I wanted things to work is that we add the Self: Trait assumption in the ParamEnv only (and not in predicates_of). And then things that project out of traits also prove that those traits hold (e.g., method invocation code etc). But it wasn't obvious to me how to do that cleanly -- in some sense, the predicates_of and predicates_defined_on split was our attempt to do that cleanly.

@nikomatsakis
Copy link
Contributor Author

@bors delegate=scalexm

@bors
Copy link
Contributor

bors commented Jun 29, 2018

✌️ @scalexm can now approve this pull request

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:56:09] ...............................................ii.iii...............................................
[00:56:15] ...............................................................................i....................
[00:56:20] ........................i...........................................................................
[00:56:25] ...............................................................................................i....
[00:56:29] ....................................................................................F...............
[00:56:36] ....................F...............................................................................
[00:56:48] ....................................................................................................
[00:56:54] ....................................................................................................
[00:57:02] ....................................................................................................
[00:57:07] ....i...............................................................................................
---
[00:57:47] ....................................................................................................
[00:57:51] ....................................................................................................
[00:57:53]             Error
[00:57:53]         ),
[00:57:53]         msg: "type annotations required"
[00:57:53] ]
[00:57:53] 
[00:57:53] thread '[compile-fail] compile-fail/issue-21974.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:1284:13
[00:57:53] 
---
[00:57:53] 
[00:57:53] thread 'main' panicked at 'Some tests failed', tools/compiletest/src/main.rs:498:22
[00:57:53] 
[00:57:53] 
[00:57:53] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/compile-fail" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/compile-fail" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "compile-fail" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-3.9/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "3.9.1\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[00:57:53] 
[00:57:53] 
[00:57:53] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[00:57:53] Build completed unsuccessfully in 0:14:52
[00:57:53] Build completed unsuccessfully in 0:14:52
[00:57:53] Makefile:58: recipe for target 'check' failed
[00:57:53] make: *** [check] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:062b2957
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

pub fn identity<'a, 'gcx>(tcx: TyCtxt<'a, 'gcx, 'tcx>, def_id: DefId) -> TraitRef<'tcx> {
TraitRef {
def_id,
substs: Substs::identity_for_item(tcx, def_id),
Copy link
Member

Choose a reason for hiding this comment

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

Can you make sure no existing code uses identity_for_item with TraitRef?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah

Copy link
Contributor Author

Choose a reason for hiding this comment

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

found a few uses, commit incoming

DefPathData::Trait(_) => true,
_ => false,
}
}
Copy link
Member

Choose a reason for hiding this comment

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

Why is this a free function and not a method on tcx? Also it's a bit sad to see such a specific hack but I don't have any good suggestion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good question, should be a method on tcx I agree. By hack you are referring to the whole param-env change, right? (Not the fn itself)

I'm somewhat torn, as I wrote elsewhere -- in a way, I think adding things to param-env is the right behavior -- or maybe the answer is that predices_of on traits should include Self: Trait but WF should use predicates_defined_on.

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:43] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:44] tidy error: /checkout/src/librustc/traits/object_safety.rs:390: line longer than 100 chars
[00:04:45] some tidy checks failed
[00:04:45] 
[00:04:45] 
[00:04:45] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:45] 
[00:04:45] 
[00:04:45] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:45] Build completed unsuccessfully in 0:01:52
[00:04:45] Build completed unsuccessfully in 0:01:52
[00:04:45] Makefile:79: recipe for target 'tidy' failed
[00:04:45] make: *** [tidy] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:06572b28
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:0c941bec:start=1530270530316800648,finish=1530270530324793085,duration=7992437
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0cb24100
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0244fac9
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@nikomatsakis nikomatsakis force-pushed the move-self-trait-predicate-to-items branch from f461fde to 2772f57 Compare June 29, 2018 11:35
@nikomatsakis
Copy link
Contributor Author

Regarding the param_env change, I'm pulling out this part of my earlier comment for further thought:

I'm somewhat torn, as I wrote elsewhere -- in a way, I think adding things to param-env is the right behavior -- or maybe the answer is that predices_of on traits should include Self: Trait but WF should use predicates_defined_on.

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:37] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:38] tidy error: /checkout/src/librustc/traits/object_safety.rs:390: line longer than 100 chars
[00:04:39] some tidy checks failed
[00:04:39] 
[00:04:39] 
[00:04:39] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:39] 
[00:04:39] 
[00:04:39] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:39] Build completed unsuccessfully in 0:01:44
[00:04:39] Build completed unsuccessfully in 0:01:44
[00:04:39] Makefile:79: recipe for target 'tidy' failed
[00:04:39] make: *** [tidy] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0a26d257
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:195f5bab:start=1530273075666930209,finish=1530273075674833508,duration=7903299
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:04f5a092
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0bc75870
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@nikomatsakis
Copy link
Contributor Author

OK, so I've been thinking a bit more about this. I didn't fully remember how the predicates_of query works -- in particular, it returns the predicates on the current item but includes only the def-d of the parent (the list is unrolled in the instantiate step).

this has got me wondering. Maybe we should do this:

  • Keep the predicates_defined_on split
  • Add Self: Trait to predicates_of for the trait
  • Have the WF requirements use predicates_defined_on and not predicates_of

Then we can not change ParamEnv (it uses predicates_of); we don't have to change the method "comparison" code (though we can) -- it works today because the Self: Trait is found in the parent predicate list, which is ignored. We don't have to change the object safety code either (though, again, we can), since it too ignores the parent list.

In fact, predicates_defined_on could maybe be called wf_predicates_of or something -- for everything but traits, this is the same as predicates_of.

@tmandry
Copy link
Member

tmandry commented Jun 30, 2018

Add Self: Trait to predicates_of for the trait

Either way sounds fine to me.

Picking the minimally invasive path makes sense. Would this roll back some of the changes you made to tests? I hit some of those, and decided it was best for this change not to modify current behavior (unless it's fixing a clear deficiency.)

Also, it seems we've come full circle on predicates_of 😅

@nikomatsakis
Copy link
Contributor Author

@tmandry it would not affect the tests. We could keep the current behavior by making the "well-formed" rules using predicates_of, not predicates_defined_on. I'm torn because keeping the behavior seems good but then that behavior is also wrong.

@nikomatsakis
Copy link
Contributor Author

Also, it seems we've come full circle on predicates_of 😅

Yeah =) that design is basically saying "predicates_of was right as is, but we needed something else sometimes". =)

@tmandry
Copy link
Member

tmandry commented Jun 30, 2018

I'm torn because keeping the behavior seems good but then that behavior is also wrong.

So with the change, the behavior is still wrong, just manifested differently, correct?

I would only be worried about other unintended consequences we don't currently test for. Admittedly I don't understand the cause of the wrong behavior in the first place, which is why I'm apprehensive.

I'm also assuming that these WF checks will be subsumed by chalk at some point.

@nikomatsakis
Copy link
Contributor Author

I just pushed a new commit with the approach I outlined here.

So with the change, the behavior is still wrong, just manifested differently, correct?

On the branch as I have it now, the behavior is not wrong. That is, proving that T: Trait is well-formed does not require proving that T: Trait is true. However...

I would only be worried about other unintended consequences we don't currently test for. Admittedly I don't understand the cause of the wrong behavior in the first place, which is why I'm apprehensive....I'm also assuming that these WF checks will be subsumed by chalk at some point.

Yes, this is the source of my apprehension as well. We've certainly hit surprises when touching things like this. It might be wise to try to leave the behavior of rustc unaffected and then let chalk fix things in a more principled way, no question.

I'm not sure what consequences this change might have. We could try a crater run to see. I'm reminded though of some of the complications we encountered after #48557 landed.

OK, here is a proposal: I will make this PR preserve behavior (but help with Chalk) and we can land it. Then I will open a separate PR that fixes the WF behavior and we can do a crater run.

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:46] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:47] tidy error: /checkout/src/librustc/traits/object_safety.rs:390: line longer than 100 chars
[00:04:48] some tidy checks failed
[00:04:48] 
[00:04:48] 
[00:04:48] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:48] 
[00:04:48] 
[00:04:48] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:48] Build completed unsuccessfully in 0:01:37
[00:04:48] Build completed unsuccessfully in 0:01:37
[00:04:48] make: *** [tidy] Error 1
[00:04:48] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:00d3b528
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:01337156:start=1530439448091204368,finish=1530439448098068594,duration=6864226
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:00149e7a
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:3226499a
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@nikomatsakis
Copy link
Contributor Author

OK, the most recent commit reverts rustc's "WF" behavior so that proving that T: Foo is well-formed also requires proving T: Foo. This definitely seems wrong to me but it avoids affecting any tests -- the remaining tests that are affected are from a drive-by rewrite of the code around defaulted bounds, which I'd prefer to keep, and anyway it only affects the details of the error message, not which errors you get.

@nikomatsakis
Copy link
Contributor Author

I'll cleanup the commit history again

nikomatsakis and others added 4 commits July 2, 2018 10:38
If we have

```rust
struct Foo<T: Copy = String> { .. }
```

the old code would have proven that `String: Copy` was WF -- this,
incidentally, also proved that `String: Copy`. The new code just
proves `String: Copy` directly.

Co-authored-by: Tyler Mandry <tmandry@gmail.com>
Co-authored-by: Tyler Mandry <tmandry@gmail.com>
Co-authored-by: Tyler Mandry <tmandry@gmail.com>
Co-authored-by: Tyler Mandry <tmandry@gmail.com>
@nikomatsakis
Copy link
Contributor Author

Cleaned up the history now.

@nikomatsakis nikomatsakis force-pushed the move-self-trait-predicate-to-items branch from 610f181 to 0f403a3 Compare July 2, 2018 14:38
// For traits, add `Self: Trait` predicate. This is
// not part of the predicates that a user writes, but it
// is something that one must prove in order to invoke a
// method method or project an associated type.
Copy link
Member

Choose a reason for hiding this comment

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

Duplicate word « method »

This new query returns only the predicates *directly defined* on an
item (in contrast to the more common `predicates_of`, which returns
the predicates that must be proven to reference an item). These two
sets are almost always identical except for traits, where
`predicates_of` includes an artificial `Self: Trait<...>` predicate
(basically saying that you cannot use a trait item without proving
that the trait is implemented for the type parameters).

This new query is only used in chalk lowering, where this artificial
`Self: Trait` predicate is problematic. We encode it in metadata but
only where needed since it is kind of repetitive with existing
information.

Co-authored-by: Tyler Mandry <tmandry@gmail.com>
@nikomatsakis nikomatsakis force-pushed the move-self-trait-predicate-to-items branch from 0f403a3 to 90ea49b Compare July 2, 2018 15:33
@nikomatsakis
Copy link
Contributor Author

@bors r=scalexm

@bors
Copy link
Contributor

bors commented Jul 2, 2018

📌 Commit 90ea49b has been approved by scalexm

@bors 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 Jul 2, 2018
@bors
Copy link
Contributor

bors commented Jul 3, 2018

⌛ Testing commit 90ea49b with merge 59ebefd20b923a856b47b6f354f8b895888c132d...

@bors
Copy link
Contributor

bors commented Jul 3, 2018

💔 Test failed - status-travis

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 3, 2018
@rust-highfive
Copy link
Collaborator

The job dist-i686-apple of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:04:12]       Memory: 8 GB
[00:04:12]       Boot ROM Version: VMW71.00V.0.B64.1704110547
[00:04:12]       Apple ROM Info: [MS_VM_CERT/SHA1/27d66596a61c48dd3dc7216fd715126e33f59ae7]Welcome to the Virtual Machine
[00:04:12]       SMC Version (system): 2.8f0
[00:04:12]       Serial Number (system): VMzcdHi9sZvn
[00:04:12] 
[00:04:12] hw.ncpu: 4
[00:04:12] hw.byteorder: 1234
[00:04:12] hw.memsize: 8589934592
---
$ rvm $(travis_internal_ruby) --fuzzy do ruby -S gem install dpl
Warning, new version of rvm available '1.29.4', you are using older version '1.29.3'.
You can disable this warning with:    echo rvm_autoupdate_flag=0 >> ~/.rvmrc
You can enable  auto-update  with:    echo rvm_autoupdate_flag=2 >> ~/.rvmrc
ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
    Errno::EHOSTUNREACH: Failed to open TCP connection to api.rubygems.org:443 (No route to host - connect(2) for "api.rubygems.org" port 443) (https://api.rubygems.org/quick/Marshal.4.8/dpl-1.9.7.gemspec.rz)


The command "rvm $(travis_internal_ruby) --fuzzy do ruby -S gem install dpl" failed and exited with 1 during .
Your build has been stopped.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

1 similar comment
@rust-highfive
Copy link
Collaborator

The job dist-i686-apple of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:04:12]       Memory: 8 GB
[00:04:12]       Boot ROM Version: VMW71.00V.0.B64.1704110547
[00:04:12]       Apple ROM Info: [MS_VM_CERT/SHA1/27d66596a61c48dd3dc7216fd715126e33f59ae7]Welcome to the Virtual Machine
[00:04:12]       SMC Version (system): 2.8f0
[00:04:12]       Serial Number (system): VMzcdHi9sZvn
[00:04:12] 
[00:04:12] hw.ncpu: 4
[00:04:12] hw.byteorder: 1234
[00:04:12] hw.memsize: 8589934592
---
$ rvm $(travis_internal_ruby) --fuzzy do ruby -S gem install dpl
Warning, new version of rvm available '1.29.4', you are using older version '1.29.3'.
You can disable this warning with:    echo rvm_autoupdate_flag=0 >> ~/.rvmrc
You can enable  auto-update  with:    echo rvm_autoupdate_flag=2 >> ~/.rvmrc
ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
    Errno::EHOSTUNREACH: Failed to open TCP connection to api.rubygems.org:443 (No route to host - connect(2) for "api.rubygems.org" port 443) (https://api.rubygems.org/quick/Marshal.4.8/dpl-1.9.7.gemspec.rz)


The command "rvm $(travis_internal_ruby) --fuzzy do ruby -S gem install dpl" failed and exited with 1 during .
Your build has been stopped.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@nikomatsakis
Copy link
Contributor Author

@bors retry

@bors 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 Jul 4, 2018
@nikomatsakis
Copy link
Contributor Author

cc @rust-lang/infra -- I'm assuming these errors reported above are spurious:

[00:04:12]       Memory: 8 GB
[00:04:12]       Boot ROM Version: VMW71.00V.0.B64.1704110547
[00:04:12]       Apple ROM Info: [MS_VM_CERT/SHA1/27d66596a61c48dd3dc7216fd715126e33f59ae7]Welcome to the Virtual Machine
[00:04:12]       SMC Version (system): 2.8f0
[00:04:12]       Serial Number (system): VMzcdHi9sZvn
[00:04:12] 
[00:04:12] hw.ncpu: 4
[00:04:12] hw.byteorder: 1234
[00:04:12] hw.memsize: 8589934592
---
$ rvm $(travis_internal_ruby) --fuzzy do ruby -S gem install dpl
Warning, new version of rvm available '1.29.4', you are using older version '1.29.3'.
You can disable this warning with:    echo rvm_autoupdate_flag=0 >> ~/.rvmrc
You can enable  auto-update  with:    echo rvm_autoupdate_flag=2 >> ~/.rvmrc
ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
    Errno::EHOSTUNREACH: Failed to open TCP connection to api.rubygems.org:443 (No route to host - connect(2) for "api.rubygems.org" port 443) (https://api.rubygems.org/quick/Marshal.4.8/dpl-1.9.7.gemspec.rz)

@bors
Copy link
Contributor

bors commented Jul 4, 2018

⌛ Testing commit 90ea49b with merge 8dd715e...

bors added a commit that referenced this pull request Jul 4, 2018
…s, r=scalexm

Move self trait predicate to items

This is a "reimagination" of @tmandry's PR #50183. The main effect is described in this comment from one of the commits:

---

Before we had the following results for `predicates_of`:

```rust
trait Foo { // predicates_of: Self: Foo
  fn bar(); // predicates_of: Self: Foo (inherited from trait)
}
```

Now we have removed the `Self: Foo` from the trait. However, we still
add it to the trait ITEM. This is because when people do things like
`<T as Foo>::bar()`, they still need to prove that `T: Foo`, and
having it in the `predicates_of` seems to be the cleanest way to
ensure that happens right now (otherwise, we'd need special case code
in various places):

```rust
trait Foo { // predicates_of: []
  fn bar(); // predicates_of: Self: Foo
}
```

However, we sometimes want to get the list of *just* the predicates
truly defined on a trait item (e.g., for chalk, but also for a few
other bits of code). For that, we define `predicates_defined_on`,
which does not contain the `Self: Foo` predicate yet, and we plumb
that through metadata and so forth.

---

I'm assigning @eddyb as the main reviewer, but I thought I might delegate to scalexm for this one in any case. I also want to post an alternative that I'll leave in the comments; it occurred to me as I was writing. =)

r? @eddyb
cc @scalexm @tmandry @leodasvacas
@bors
Copy link
Contributor

bors commented Jul 4, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: scalexm
Pushing 8dd715e to master...

@bors bors merged commit 90ea49b into rust-lang:master Jul 4, 2018
@tmandry tmandry added the WG-traits Working group: Traits, https://internals.rust-lang.org/t/announcing-traits-working-group/6804 label May 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. WG-traits Working group: Traits, https://internals.rust-lang.org/t/announcing-traits-working-group/6804
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants