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

[WIP] Trait upcasting #60900

Open
wants to merge 4 commits into
base: master
from

Conversation

@alexreg
Copy link
Contributor

commented May 17, 2019

Allows casting objects of type dyn Foo to dyn Bar whenever Foo: Bar.

r? @eddyb

CC @nikomatsakis

@alexreg

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2019

@eddyb This isn't complete yet, but an initial review would be appreciated. Also, if you could elaborate slightly on what remains, that would be helpful. (At the moment I don't think upcast objects get the right vtable pointer still, i.e. it just points to the start of the overall vtable, not the "subtable".)

@alexreg alexreg force-pushed the alexreg:trait-upcasting branch from 7d22843 to 853fe8b May 17, 2019

@rust-highfive

This comment was marked as resolved.

Copy link
Collaborator

commented May 17, 2019

The job x86_64-gnu-llvm-6.0 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.
travis_time:end:17099164:start=1558057407479717719,finish=1558057408257664890,duration=777947171
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---

[00:04:39] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:40] tidy error: /checkout/src/librustc_mir/interpret/traits.rs:72: 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:13
[00:04:45] Build completed unsuccessfully in 0:01:13
[00:04:45] make: *** [tidy] Error 1
[00:04:45] Makefile:67: recipe for target 'tidy' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:00242208
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Fri May 17 01:48:24 UTC 2019
---
travis_time:end:1bb591e8:start=1558057705530804580,finish=1558057705536177464,duration=5372884
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:15be9842
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:1bfbed31
travis_time:start:1bfbed31
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:08bc628d
$ 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)

Show resolved Hide resolved src/librustc/mir/interpret/pointer.rs Outdated
Show resolved Hide resolved src/librustc/mir/interpret/pointer.rs Outdated
Show resolved Hide resolved src/librustc/mir/interpret/pointer.rs Outdated
Show resolved Hide resolved src/librustc/traits/select.rs
Show resolved Hide resolved src/librustc/traits/select.rs Outdated
///
/// A Rust trait object type consists (in addition to a lifetime bound)
/// of a set of trait bounds, which are separated into any number
/// of auto-trait bounds, and at most 1 non-auto-trait bound. The
/// of auto-trait bounds, and at most one non-auto-trait bound. The
/// non-auto-trait bound is called the "principal" of the trait

This comment has been minimized.

Copy link
@Centril

Centril May 17, 2019

Member

I thought we had done away with "principal"? (don't change it here... just... we should fix this sometime?)

This comment has been minimized.

Copy link
@alexreg

alexreg May 17, 2019

Author Contributor

Yeah, we kind of did, in my other PR (not yet merged), but it turns out there's a few more things. Easy to remove though.

Show resolved Hide resolved src/librustc_codegen_ssa/meth.rs
Show resolved Hide resolved src/librustc_mir/interpret/traits.rs
Show resolved Hide resolved src/librustc_mir/interpret/traits.rs
Show resolved Hide resolved src/librustc_mir/monomorphize/collector.rs Outdated
@oli-obk

This comment has been minimized.

Copy link
Contributor

commented May 17, 2019

Do you have some links to the related discussion, issues, RFCs?

Am I right in assuming that the current unfinished implementation will allow casting dyn Foo to Bar and Boo if Foo: Bar + Foo, even though one of these is definitely not possible because the vtables can't match? So the implementation strategy is solely for zero cost upcasting where the start of Foo's vtable is equal to the start of Bar's vtable?

@oli-obk

This comment has been minimized.

Copy link
Contributor

commented May 17, 2019

I just want to note that a rate of (optimistic counting) 70 semantic diff lines to over 250 cosmetic changes is not too great (Thank you for mostly splitting it out into separate commits though!). Please consider keeping this closer to rates of other contributors in the future.

ptr_align,
MemoryKind::Vtable,
);
let tcx = &*self.tcx;

let mut cur_ptr = vtable;

This comment has been minimized.

Copy link
@oli-obk

oli-obk May 17, 2019

Contributor

Everything below here in this function could be in a separate commit, as it's just a (very good!) cleanup.

@rust-highfive

This comment was marked as outdated.

Copy link
Collaborator

commented May 17, 2019

The job x86_64-gnu-llvm-6.0 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.
travis_time:end:00a03ab2:start=1558114152225209133,finish=1558114244061390450,duration=91836181317
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---

[00:03:52] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:03:52] tidy error: /checkout/src/librustc_mir/interpret/traits.rs:72: line longer than 100 chars
[00:03:57] some tidy checks failed
[00:03:57] 
[00:03:57] 
[00:03:57] 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:03:57] 
[00:03:57] 
[00:03:57] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:57] Build completed unsuccessfully in 0:01:14
[00:03:57] Build completed unsuccessfully in 0:01:14
[00:03:57] Makefile:67: recipe for target 'tidy' failed
[00:03:57] make: *** [tidy] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0a360962
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Fri May 17 17:34:50 UTC 2019
---
travis_time:end:009ae576:start=1558114490787670803,finish=1558114490792468475,duration=4797672
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:3704557a
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0ab054f0
travis_time:start:0ab054f0
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:38faf660
$ 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)

@alexreg

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2019

I just want to note that a rate of (optimistic counting) 70 semantic diff lines to over 250 cosmetic changes is not too great (Thank you for mostly splitting it out into separate commits though!). Please consider keeping this closer to rates of other contributors in the future.

You're right, it's a bit excessive, sorry... I have to try to rein in my natural tendencies! They'll be very minimal from now on in this PR, I think. :-) And in future PRs maybe a max 1:1 ratio (roughly) sounds good, I guess.

Anyway, thanks for the reviews @Centril and @oli-obk! Will push my updates presently, after which you're welcome to either rereview or wait for @eddyb.

@alexreg

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2019

Do you have some links to the related discussion, issues, RFCs?

Am I right in assuming that the current unfinished implementation will allow casting dyn Foo to Bar and Boo if Foo: Bar + Foo, even though one of these is definitely not possible because the vtables can't match? So the implementation strategy is solely for zero cost upcasting where the start of Foo's vtable is equal to the start of Bar's vtable?

I presume you meant Boo: Bar + Foo? This PR isn't allowing multi-trait objects though, so we don't need to worry about such cases unless one of Foo or Bar is an auto-trait, in which case the vtable isn't affected.

Anyway, for background, @nikomatsakis and I have discussed this feature informally for some time now, and we had a conversation on Zulip a few weeks ago, which @eddyb also participated in – I believe Eddy tagged you in a question right at the end and you replied, so you might have seen some of it? He explains the vtable layout in any case (which I may have gotten wrong in this PR, but hopefully not).

I believe the plan of action is to review & merge this PR under "experimentation in master", but write up an RFC simultaneously, if possible. I forget if anyone already volunteered for that (@Centril)?

@Centril

This comment has been minimized.

Copy link
Member

commented May 17, 2019

I believe the plan of action is to review & merge this PR under "experimentation in master", but write up an RFC simultaneously, if possible. I forget if anyone already volunteered for that (@Centril)?

Yep; just need to find the time somehow =)

@oli-obk

This comment has been minimized.

Copy link
Contributor

commented May 17, 2019

I am not talking about multi-trait object, but about traits with multiple parents:

trait A {
    fn a(&self) {}
}

trait B {
    fn b(&self) {}
}

trait Foo: A + B {}

impl A for () {}
impl B for () {}
impl Foo for () {}


fn main() {
    let x: &Foo = &();
    let y: &A = x;
}

Right now this will be unsound with the implementation at hand.

tagged you in a question right at the end and you replied, so you might have seen some of it?

Ah yes I remember, I mostly thought we were talking about deduplicating the vtable generation :D

I believe the plan of action is to review & merge this PR under "experimentation in master", but write up an RFC simultaneously, if possible.

Ok, can you open a tracking issue with some info about what's being done so PRs can reference it and we have a sort of central point to talk about things and collect links?


/*

This comment has been minimized.

Copy link
@oli-obk

oli-obk May 17, 2019

Contributor

So basically right now all that needs doing is put a feature gate check around this code instead of uncommenting? (in order to get upcasting to parent traits if there is only a single parent trait?)

This comment has been minimized.

Copy link
@alexreg

alexreg May 17, 2019

Author Contributor

Yeah, basically. I'll want to feature gate data_a.principal_def_id() == data_b.principal_def_id() in assemble_candidates_for_unsizing too, but that's probably about it.

@Centril

This comment has been minimized.

Copy link
Member

commented May 17, 2019

Ok, can you open a tracking issue with some info about what's being done so PRs can reference it and we have a sort of central point to talk about things and collect links?

That sounds good; the current discussion has been centered in https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/object.20upcasting.

@alexreg

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2019

Presently, bootstrapping this PR yields the following stage1 error:

error[E0283]: type annotations required: cannot resolve `dyn emitter::Emitter + rustc_data_structures::sync::Send: rustc_data_structures::sync::Send`
   --> src/librustc_errors/lib.rs:391:13
    |
391 |             e,
    |             ^
    |
    = note: required for the cast to the object type `dyn emitter::Emitter + rustc_data_structures::sync::Send`

error: aborting due to previous error

Any ideas?

@alexreg alexreg force-pushed the alexreg:trait-upcasting branch from 133a81f to ba45c8f May 17, 2019

@alexreg

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2019

@oli-obk

I am not talking about multi-trait object, but about traits with multiple parents:

trait A {
    fn a(&self) {}
}

trait B {
    fn b(&self) {}
}

trait Foo: A + B {}

impl A for () {}
impl B for () {}
impl Foo for () {}


fn main() {
    let x: &Foo = &();
    let y: &A = x;
}

Right now this will be unsound with the implementation at hand.

I'm probably missing something obvious... could you elaborate?

tagged you in a question right at the end and you replied, so you might have seen some of it?

Ah yes I remember, I mostly thought we were talking about deduplicating the vtable generation :D

Hah, yep, that was just a natural side-topic stemming from eddyb and I chatting about how to go about implementing this feature. :-)

I believe the plan of action is to review & merge this PR under "experimentation in master", but write up an RFC simultaneously, if possible.

Ok, can you open a tracking issue with some info about what's being done so PRs can reference it and we have a sort of central point to talk about things and collect links?

Will do shortly.

@oli-obk

This comment has been minimized.

Copy link
Contributor

commented May 17, 2019

Any ideas?

The code you commented out does this relating. I presume the result of the equality check not ending up in the nested variable causes Trait + Send to be upcastable to neither Send nor Trait

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented May 17, 2019

The job x86_64-gnu-llvm-6.0 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.
travis_time:end:0fa70be6:start=1558126492135971338,finish=1558126591477599402,duration=99341628064
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:31:08]    Compiling synstructure v0.10.1
[00:31:35]    Compiling rustc_macros v0.1.0 (/checkout/src/librustc_macros)
[00:31:44]    Compiling syntax_pos v0.0.0 (/checkout/src/libsyntax_pos)
[00:31:49]    Compiling rustc_errors v0.0.0 (/checkout/src/librustc_errors)
[00:31:49] error[E0283]: type annotations required: cannot resolve `dyn emitter::Emitter + rustc_data_structures::sync::Send: rustc_data_structures::sync::Send`
[00:31:49]     |
[00:31:49] 391 |             e,
[00:31:49]     |             ^
[00:31:49]     |
[00:31:49]     |
[00:31:49]     = note: required for the cast to the object type `dyn emitter::Emitter + rustc_data_structures::sync::Send`
[00:31:50] error: aborting due to previous error
[00:31:50] 
[00:31:50] For more information about this error, try `rustc --explain E0283`.
[00:31:50] error: Could not compile `rustc_errors`.
---
156496 ./src/llvm-project/clang
145168 ./obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu
145164 ./obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release
142472 ./obj/build/bootstrap/debug/incremental/bootstrap-gm2kk8y15os9
142468 ./obj/build/bootstrap/debug/incremental/bootstrap-gm2kk8y15os9/s-fcb5jjwfjh-1bn7ic2-34hadj2q5a3fu
123644 ./src/llvm-project/llvm/test/CodeGen
108532 ./src/llvm-project/lldb
97584 ./src/llvm-project/clang/test
89964 ./src/llvm-emscripten/test/CodeGen
---
travis_time:end:1b13fafe:start=1558128511368520562,finish=1558128511373232229,duration=4711667
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0a8d6488
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || 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)

@alexreg

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2019

The code you commented out does this relating. I presume the result of the equality check not ending up in the nested variable causes Trait + Send to be upcastable to neither Send nor Trait

Right, but shouldn't the subsequent bit beginning // Register an obligation for `dyn TraitA: TraitB`. cover for that?

Edit: maybe it's as simple as keeping that code and changing .eq to .lub...

// Register an obligation for `dyn TraitA: TraitB`.
nested.extend(
data_b.iter()
.map(|d| predicate_to_obligation(d.with_self_ty(tcx, source_ty))),

This comment has been minimized.

Copy link
@oli-obk

oli-obk May 17, 2019

Contributor

Maybe this gives you a Prediate::Trait, when you want a Predicate::Subtype? I don't know this code very well, I'm not sure I can be of much help here.

This comment has been minimized.

Copy link
@alexreg

alexreg May 17, 2019

Author Contributor

I already showed this bit to eddyb a few days ago, and he thought it was right... but you make a fair point; I'll check that out.

This comment has been minimized.

Copy link
@alexreg

alexreg May 17, 2019

Author Contributor

Well, we're dealing with an ExistentialPredicate here in fact, so there's no Subtrait... might have to wait for eddyb to review. Thanks though.

This comment has been minimized.

Copy link
@alexreg

alexreg May 18, 2019

Author Contributor

@oli-obk Interesting: having this new code plus the old code (uncommented) gives the same error!

@oli-obk

This comment has been minimized.

Copy link
Contributor

commented May 19, 2019

I'm probably missing something obvious... could you elaborate?

The vtable of () as A looks like

* ()::drop
* 1 (align)
* 0 (size)
* <() as A>::a

The vtable of () as B looks like

* ()::drop
* 1 (align)
* 0 (size)
* <() as B>::b

The vtable of () as Foo looks like

* ()::drop
* 1 (align)
* 0 (size)
* <() as A>::a
* <() as B>::b

or implementation defined as

* ()::drop
* 1 (align)
* 0 (size)
* <() as B>::b
* <() as A>::a

(note the order of a and b)

So you can only ever upcast to either A or B when going from Foo, as only one of the vtables is fully available in Foo's vtable.> I'm probably missing something obvious... could you elaborate?

The vtable of () as A looks like

* ()::drop
* 1 (align)
* 0 (size)
* <() as A>::a

The vtable of () as B looks like

* ()::drop
* 1 (align)
* 0 (size)
* <() as B>::b

The vtable of () as Foo looks like

* ()::drop
* 1 (align)
* 0 (size)
* <() as A>::a
* <() as B>::b

or implementation defined as

* ()::drop
* 1 (align)
* 0 (size)
* <() as B>::b
* <() as A>::a

(note the order of a and b)

So you can only ever upcast to either A or B when going from Foo, as only one of the vtables is fully available in Foo's vtable.

In the zulip thread there was some discussion about doing something like

* ()::drop
* 1 (align)
* 0 (size)
* <() as B>::b
* ()::drop
* 1 (align)
* 0 (size)
* <() as A>::a

for Foo's vtable in order to have both bases to upcast to. I don't remember what the discussion on that was, and it also makes this feature not zero cost, so I don't see how to enable this feature without impacting stable users except by restricting it to upcasts for traits with a single base trait.

Though the memory regression is probably very small, it may still have a bad impact on embedded devs.

@alexreg

This comment has been minimized.

Copy link
Contributor Author

commented May 19, 2019

In the zulip thread there was some discussion about doing something like

Oh, I thought that's what I did implement already... I'm pretty sure it is, in fact. Can you explain why it isn't?

@oli-obk

This comment has been minimized.

Copy link
Contributor

commented May 22, 2019

Ah, you're right. I misread the loop in meth.rs.

I'm not sure how to measure the impact of this. This will have some effect on binary sizes I presume (since all vtables of traits with multiple parent traits will now be bigger by 24 bytes per parent trait beyond the first).

@alexreg

This comment has been minimized.

Copy link
Contributor Author

commented May 22, 2019

@oli-obk Yeah... I think we (@nikomatsakis, @eddyb, myself) just implicitly discounted that as not so important during our conversation. If it's really a concern, maybe there's some sort of crater-like test we can run? I do think it's a very reasonable and small "hit" to take in any case.

@oli-obk

This comment has been minimized.

Copy link
Contributor

commented May 25, 2019

I think it would be fine to just check by how much libstd and maybe some other large crates like cargo change their binary size. If it's negligible then we can just ignore it.

@alexreg

This comment has been minimized.

Copy link
Contributor Author

commented May 26, 2019

Sounds reasonable.

@bors

This comment has been minimized.

Copy link
Contributor

commented May 28, 2019

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

@alexreg alexreg force-pushed the alexreg:trait-upcasting branch from ba45c8f to f061305 Jun 6, 2019

@alexreg

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2019

@rust-highfive rust-highfive assigned nikomatsakis and unassigned eddyb Jun 6, 2019

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented Jun 6, 2019

The job x86_64-gnu-llvm-6.0 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.
travis_time:end:09e0a2e8:start=1559788856592022092,finish=1559788945367792987,duration=88775770895
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:29:49]    Compiling synstructure v0.10.2
[00:30:13]    Compiling rustc_macros v0.1.0 (/checkout/src/librustc_macros)
[00:30:21]    Compiling syntax_pos v0.0.0 (/checkout/src/libsyntax_pos)
[00:30:26]    Compiling rustc_errors v0.0.0 (/checkout/src/librustc_errors)
[00:30:27] error[E0283]: type annotations required: cannot resolve `dyn emitter::Emitter + rustc_data_structures::sync::Send: rustc_data_structures::sync::Send`
[00:30:27]     |
[00:30:27] 392 |             e,
[00:30:27]     |             ^
[00:30:27]     |
---
166976 ./obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps
156504 ./src/llvm-project/clang
150608 ./obj/build/bootstrap/debug/incremental
135324 ./obj/build/bootstrap/debug/incremental/bootstrap-oxgzobynhmm1
135320 ./obj/build/bootstrap/debug/incremental/bootstrap-oxgzobynhmm1/s-fcwd815idg-arple9-3h3kftrpru154
120468 ./obj/build/x86_64-unknown-linux-gnu/stage1-rustc
108532 ./src/llvm-project/lldb
98164 ./obj/build/x86_64-unknown-linux-gnu/stage1-std
98036 ./obj/build/x-analysis/test_data
---
24124 ./src/llvm-projec797459669107,finish=1559790797467187798,duration=7518691
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:1741906e
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:1a9543d3
$ 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)

@bors

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2019

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

@Dylan-DPC

This comment has been minimized.

Copy link
Member

commented Jul 1, 2019

ping from triage @nikomatsakis any updates? @alexreg you have conflicts to resolve

@alexreg

This comment has been minimized.

Copy link
Contributor Author

commented Jul 1, 2019

@Dylan-DPC Not going to resolve to after review, as this has been sitting for a while and could sit for a while more. ;-)


// Register an obligation for `'a: 'b`.
let outlives = ty::OutlivesPredicate(region_a, region_b);
nested.push(predicate_to_obligation(

This comment has been minimized.

Copy link
@nikomatsakis

nikomatsakis Jul 5, 2019

Contributor

Nit: seems like you lost the recursion_depth + 1 count here.

This comment has been minimized.

Copy link
@alexreg

alexreg Aug 5, 2019

Author Contributor

Have I actually? predicate_to_obligation does recursion_depth + 1 so I this is okay... I think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.