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

Add Into<NonNull<T>> impls for Box<T>/Arc<T>/Rc<T> #56998

Closed
wants to merge 14 commits into
base: master
from

Conversation

Projects
None yet
@dwijnand
Copy link
Member

dwijnand commented Dec 19, 2018

/cc @withoutboats who mentioned to me this might be worth adding to the standard library, in withoutboats/smart#4
/cc @kennytm who last year didn't love the idea of having an Into<NonNull> for Box, in #46952

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Dec 19, 2018

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Dec 20, 2018

Thanks for the PR! This seems reasonable to me, but I'm double checking the rest of libstd for other idioms. It looks like this isn't implemented for Box, the other obvious candidate. The Box type, however, has an into_raw_non_null unstable method for doing the same thing (just not via a trait).

The Box::into_raw_non_null method was added in #46952 and looks like at least at one point it was From but ended up switching back. @SimonSapin do you recall why we opted for not having a From/Into impl between the NonNull and Box types?

I think that leaves us with two routes to go here:

  • Land these as stable, also removing Box::into_raw_non_null in favor of the same pattern here. Note that if we do this I think we'll want to use From impls instead of Into which are slightly more general.
  • Land these as unstable, renaming to Arc::into_raw_non_null to mirror Box.

I'd ideally like to hear from @SimonSapin first to see if they remember why we didn't do Into in the first place.

@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Dec 20, 2018

From is not possible because NonNull is in libcore and Arc/Rc is in liballoc, so according to the laws of coherence it can't be implemented.

So the options left are implementing Into or implementing it as an inherent method. (Or option 3, wait for that coherency rule to be lifted via RFC).

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Dec 20, 2018

do you recall why we opted for not having a From/Into impl between the NonNull and Box types?

#46952 (comment) mentions that we generally avoid methods that take self (rather than associated functions that take Self) on generic smart pointers like Box<T> because it could shadow a method of the same name on T.

Perhaps more importantly, #46952 (comment) says I undid that because of a incoherent_fundamental_impls warning: #46205

Box is #[fundamental] so adding impls for it of existing traits is a breaking change as far as I understand. #56955 proposes adding #[fundamental] to Arc and Rc.

we'll want to use From impls instead of Into which are slightly more general

IIRC coherence does not allow this, since NonNull is defined in libcore but Arc and Rc in liballoc.

@withoutboats

This comment has been minimized.

Copy link
Contributor

withoutboats commented Dec 20, 2018

Yes, for box its a potentially breaking change because someone could have implemented Into<NonNull<MyType>> for Box<MyType> because its fundamental. We'd need to at least do a crater run.

I personally prefer using standard conversion methods here, especially since we already do that for references, to avoid users having to look up methods with names like into_raw_non_null.

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Dec 20, 2018

I don't think coherence blocks this, so @dwijnand want to switch to From, add an impl for Box, and we can see what the fallout is on crater?

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Dec 20, 2018

@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Dec 20, 2018

Yeah... Over on Zulip I've been pointed to https://github.com/rust-lang/rfcs/blob/master/text/2451-re-rebalancing-coherence.md, which points to #55437 and thus #56145. So if we want to use From and make Box work the same way, we could block this on that PR landing.

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Dec 20, 2018

we generally avoid methods that take self (rather than associated functions that take Self) on generic smart pointers like Box<T> because it could shadow a method of the same name on T.

I guess this is the remaining concern with an Into impl for Box (even through a From one). @rust-lang/libs, any thoughts on this?

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Dec 20, 2018

Oh oops, my mistake! @dwijnand want to switch to Into for Box and we can crater?

I'll hold of on formulating whether it's a good idea until we've tested it on crater :)

@withoutboats

This comment has been minimized.

Copy link
Contributor

withoutboats commented Dec 20, 2018

I'll also note that there's an active lang RFC to change coherence in a way that I think would allow From & we are generally inclined to merge, but I also think its backward compatible to switch the Into to From

@dwijnand

This comment was marked as resolved.

Copy link
Member

dwijnand commented Dec 23, 2018

Hey @alexcrichton, sorry I forgot about your request here until now.

I tried implementing Into for Box, but got:

error: conflicting implementations of trait `core::convert::Into<core::ptr::NonNull<_>>` for type `boxed::Box<_>`: (E0119)
   --> src/liballoc/boxed.rs:483:1
    |
483 | impl<T: ?Sized> Into<NonNull<T>> for Box<T> {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: #[deny(incoherent_fundamental_impls)] on by default
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #46205 <https://github.com/rust-lang/rust/issues/46205>
    = note: conflicting implementation in crate `core`:
            - impl<T, U> core::convert::Into<U> for T
              where U: core::convert::From<T>;
    = note: downstream crates may implement trait `core::convert::From<boxed::Box<_>>` for type `core::ptr::NonNull<_>`

Trying to allow that made my test case fail to compile:

   --> src/liballoc/boxed_test.rs:154:52
    |
154 |     let ptr: std::ptr::NonNull<i32> = Box::from(0).into();
    |                                                    ^^^^ the trait `core::convert::From<std::boxed::Box<{integer}>>` is not implemented for `core::ptr::NonNull<i32>`
    |
    = help: the following implementations were found:
              <core::ptr::NonNull<T> as core::convert::From<&'a T>>
              <core::ptr::NonNull<T> as core::convert::From<&'a mut T>>
              <core::ptr::NonNull<T> as core::convert::From<core::ptr::Unique<T>>>
    = note: required because of the requirements on the impl of `core::convert::Into<core::ptr::NonNull<i32>>` for `std::boxed::Box<{integer}>`

I then tried something else (either tweaking the impl or teaking the test, I forget), which led me to this confusing situation:

error[E0460]: found possibly newer version of crate `alloc` which `std` depends on
   --> src/liballoc/lib.rs:128:1
    |
128 | extern crate std;
    | ^^^^^^^^^^^^^^^^^
    |
    = note: perhaps that crate needs to be recompiled?
    = note: the following crate versions were found:
            crate `alloc`: /d/rust/build/x86_64-apple-darwin/stage0-std/x86_64-apple-darwin/release/deps/liballoc-755c123e9f141b95.rlib
            crate `alloc`: /d/rust/build/x86_64-apple-darwin/stage0-sysroot/lib/rustlib/x86_64-apple-darwin/lib/liballoc-755c123e9f141b95.rlib
            crate `std`: /d/rust/build/x86_64-apple-darwin/stage0-sysroot/lib/rustlib/x86_64-apple-darwin/lib/libstd-5a6b2941d398f5d5.dylib
            crate `std`: /d/rust/build/x86_64-apple-darwin/stage0-sysroot/lib/rustlib/x86_64-apple-darwin/lib/libstd-5a6b2941d398f5d5.rlib

error: aborting due to previous error

For more information about this error, try `rustc --explain E0460`.
error: Could not compile `alloc`.

To learn more, run the command again with --verbose.


command did not execute successfully: "/d/rust/build/x86_64-apple-darwin/stage0/bin/cargo" "test" "--target" "x86_64-apple-darwin" "-j" "8" "--release" "--features" "panic-unwind backtrace" "--manifest-path" "/d/rust/src/libstd/Cargo.toml" "-p" "alloc" "--" "to_nonnull" "--quiet"
expected success, got: exit code: 101


failed to run: /d/rust/build/bootstrap/debug/bootstrap test --keep-stage 0 --stage 0 src/liballoc --test-args to_nonnull
Build completed unsuccessfully in 0:00:03

So I dropped the -keep-stage 0 (which I had been using successfully, and had been recommended on Zulip) but that gave me:

error[E0460]: found possibly newer version of crate `std` which `getopts` depends on
  --> src/libtest/lib.rs:45:1
   |
45 | extern crate getopts;
   | ^^^^^^^^^^^^^^^^^^^^^
   |
   = note: perhaps that crate needs to be recompiled?
   = note: the following crate versions were found:
           crate `std`: /d/rust/build/x86_64-apple-darwin/stage0-sysroot/lib/rustlib/x86_64-apple-darwin/lib/libstd-5a6b2941d398f5d5.rlib
           crate `std`: /d/rust/build/x86_64-apple-darwin/stage0-sysroot/lib/rustlib/x86_64-apple-darwin/lib/libstd-5a6b2941d398f5d5.dylib
           crate `getopts`: /d/rust/build/x86_64-apple-darwin/stage0-test/x86_64-apple-darwin/release/deps/libgetopts-8c1bca47bf6894d5.rlib

error: aborting due to previous error

For more information about this error, try `rustc --explain E0460`.
error: Could not compile `test`.

To learn more, run the command again with --verbose.
command did not execute successfully: "/d/rust/build/x86_64-apple-darwin/stage0/bin/cargo" "build" "--target" "x86_64-apple-darwin" "-j" "8" "--release" "--manifest-path" "/d/rust/src/libtest/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
failed to run: /d/rust/build/bootstrap/debug/bootstrap test --stage 0 src/liballoc --test-args to_nonnull
Build completed unsuccessfully in 0:00:17

So I dropped my changes entirely and "Building stage0 compiler artifacts (x86_64-apple-darwin -> x86_64-apple-darwin)" took 12m30 (is that normal?) and ended up failing anyways:

     Running build/x86_64-apple-darwin/stage0-std/x86_64-apple-darwin/release/deps/alloc-4f5d60f9094e66f5

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 100 filtered out

     Running build/x86_64-apple-darwin/stage0-std/x86_64-apple-darwin/release/deps/collectionstests-afe1c7c2f5f7578e

running 2 tests
..
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 560 filtered out

   Doc-tests alloc
error: failed to find a `codegen-backends` folder in the sysroot candidates:
* /d/rust/build/x86_64-apple-darwin/stage0-tools/x86_64-apple-darwin
* /d/rust/build/x86_64-apple-darwin/stage0-sysroot/lib/rustlib/x86_64-apple-darwin
* /d/rust/build/x86_64-apple-darwin/stage0-sysroot

error: test failed, to rerun pass '--doc'


command did not execute successfully: "/d/rust/build/x86_64-apple-darwin/stage0/bin/cargo" "test" "--target" "x86_64-apple-darwin" "-j" "8" "--release" "--features" "panic-unwind backtrace" "--manifest-path" "/d/rust/src/libstd/Cargo.toml" "-p" "alloc" "--" "to_nonnull" "--quiet"
expected success, got: exit code: 1


failed to run: /d/rust/build/bootstrap/debug/bootstrap test --stage 0 src/liballoc --test-args to_nonnull
Build completed unsuccessfully in 0:08:46

Actually I just tested any change to the compiler (like an attribute string) and anything leads me to "error[E0460]: found possibly newer version of crate std which getopts depends on", so I don't think I'll be able to develop this patch any further unless I can unblock my local development of Rust...

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Dec 24, 2018

As far as I understand, found possibly newer version of crate can occur because of a bug in rustbuild and/or Cargo. One way to get out of that situation is ./x.py clean or cargo clean. (Unfortunately I don’t know a better way.)

As to the initial incoherent_fundamental_impls warning/error, this is what I mentioned before in #56998 (comment). Currently the language rules around #[fundamental] do not allow this impl. #56998 (comment) suggests that the language will be tweaked and it might be allowed later, but that has not landed yet.

@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Dec 24, 2018

Is it perhaps related to my usage of RUSTC_WRAPPER=sccache?

@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Dec 25, 2018

Anyways, thank you @SimonSapin for unblocking me, I've pushed a commit that seems to work for my test cases.

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Jan 2, 2019

@bors: try

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 2, 2019

⌛️ Trying commit 98b46ba with merge 185e079...

bors added a commit that referenced this pull request Jan 2, 2019

Auto merge of #56998 - dwijnand:from-Arc/Rc-to-NonNull, r=<try>
Add Into<NonNull<T>> impls for Arc<T>/Rc<T>

/cc @withoutboats who mentioned to me this might be worth adding to the standard library, in withoutboats/smart#4
/cc @kennytm who last year didn't love the idea of having an Into<NonNull<T>> for Box<T>, in #46952
@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Jan 3, 2019

@bors: retry

@kennytm

This comment has been minimized.

Copy link
Member

kennytm commented Jan 3, 2019

@craterbot run start=master#ec194646fef1a467073ad74b8b68f6f202cfce97 end=try#185e0799ac53f1168549e11c4fc64ebf18b4a2c1 mode=check-only

@craterbot

This comment has been minimized.

Copy link
Collaborator

craterbot commented Jan 3, 2019

👌 Experiment pr-56998 created and queued.
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@rust-highfive

This comment was marked as resolved.

Copy link
Collaborator

rust-highfive commented Jan 8, 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:0d67ba44:start=1546930071358858335,finish=1546930142107728571,duration=70748870236
$ 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
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---
[00:04:09]    Compiling rustc-std-workspace-core v1.0.0 (/checkout/src/tools/rustc-std-workspace-core)
[00:04:11]    Compiling alloc v0.0.0 (/checkout/src/liballoc)
[00:04:11]    Compiling rustc-demangle v0.1.10
[00:04:11]    Compiling panic_abort v0.0.0 (/checkout/src/libpanic_abort)
[00:04:12] warning: use of deprecated item '<boxed::Box<T>>::into_raw_non_null': Use `.into()`
[00:04:12]    --> src/liballoc/boxed.rs:167:9
[00:04:12]     |
[00:04:12] 167 |         Box::into_raw_non_null(b).as_ptr()
[00:04:12]     |
[00:04:12]     = note: #[warn(deprecated)] on by default
[00:04:12] 
[00:04:12] 
[00:04:12] warning: use of deprecated item '<boxed::Box<T>>::into_raw_non_null': Use `.into()`
[00:04:12]     |
[00:04:12]     |
[00:04:12] 149 |             let node = Some(Box::into_raw_non_null(node));
[00:04:12] 
[00:04:12] 
[00:04:12] warning: use of deprecated item '<boxed::Box<T>>::into_raw_non_null': Use `.into()`
[00:04:12]     |
[00:04:12]     |
[00:04:12] 184 |             let node = Some(Box::into_raw_non_null(node));
[00:04:12] 
[00:04:12] 
[00:04:12] warning: use of deprecated item '<boxed::Box<T>>::into_raw_non_null': Use `.into()`
[00:04:12]     |
[00:04:12]     |
[00:04:12] 926 |                 let node = Some(Box::into_raw_non_null(box Node {
[00:04:12] 
[00:04:12] 
[00:04:13] warning: use of deprecated item '<boxed::Box<T>>::into_raw_non_null': Use `.into()`
[00:04:13]     |
[00:04:13]     |
[00:04:13] 293 |         Arc { ptr: Box::into_raw_non_null(x), phantom: PhantomData }
[00:04:13] 
[00:04:15]    Compiling panic_unwind v0.0.0 (/checkout/src/libpanic_unwind)
[00:04:31]     Finished release [optimized] target(s) in 54.78s
[00:04:31] Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
---
[00:24:43]    Compiling rustc-std-workspace-core v1.0.0 (/checkout/src/tools/rustc-std-workspace-core)
[00:24:45]    Compiling alloc v0.0.0 (/checkout/src/liballoc)
[00:24:45]    Compiling panic_abort v0.0.0 (/checkout/src/libpanic_abort)
[00:24:46]    Compiling rustc-demangle v0.1.10
[00:24:47] error: use of deprecated item '<boxed::Box<T>>::into_raw_non_null': Use `.into()`
[00:24:47]    --> src/liballoc/boxed.rs:167:9
[00:24:47]     |
[00:24:47] 167 |         Box::into_raw_non_null(b).as_ptr()
[00:24:47]     |
[00:24:47]     = note: `-D deprecated` implied by `-D warnings`
[00:24:47] 
[00:24:47] 
[00:24:47] error: use of deprecated item '<boxed::Box<T>>::into_raw_non_null': Use `.into()`
[00:24:47]     |
[00:24:47]     |
[00:24:47] 149 |             let node = Some(Box::into_raw_non_null(node));
[00:24:47] 
[00:24:47] 
[00:24:47] error: use of deprecated item '<boxed::Box<T>>::into_raw_non_null': Use `.into()`
[00:24:47]     |
[00:24:47]     |
[00:24:47] 184 |             let node = Some(Box::into_raw_non_null(node));
[00:24:47] 
[00:24:47] 
[00:24:47] error: use of deprecated item '<boxed::Box<T>>::into_raw_non_null': Use `.into()`
[00:24:47]     |
[00:24:47]     |
[00:24:47] 926 |                 let node = Some(Box::into_raw_non_null(box Node {
[00:24:47] 
[00:24:47] 
[00:24:48] error: use of deprecated item '<boxed::Box<T>>::into_raw_non_null': Use `.into()`
[00:24:48]     |
[00:24:48]     |
[00:24:48] 293 |         Arc { ptr: Box::into_raw_non_null(x), phantom: PhantomData }
[00:24:48] 
[00:24:49] error: aborting due to 5 previous errors
[00:24:49] 
[00:24:49] error: Could not compile `alloc`.
[00:24:49] error: Could not compile `alloc`.
[00:24:49] 
[00:24:49] To learn more, run the command again with --verbose.
[00:24:49] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json"
[00:24:49] expected success, got: exit code: 101
[00:24:49] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap build
[00:24:49] Build completed unsuccessfully in 0:21:14
[00:24:49] make: *** [all] Error 1
[00:24:49] Makefile:18: recipe for target 'all' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:09e247d0
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Tue Jan  8 07:14:00 UTC 2019
---
travis_time:end:04b08880:start=1546931641377620227,finish=1546931641382394328,duration=4774101
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1502e956
$ 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:0d3403cf
travis_time:start:0d3403cf
$ 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:183e5778
$ 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)

@rust-highfive

This comment was marked as resolved.

Copy link
Collaborator

rust-highfive commented Jan 8, 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:03c17c8b:start=1546935829538851020,finish=1546935900580440097,duration=71041589077
$ 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
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:15:23] 
[01:15:23] running 118 tests
[01:15:49] .iiiii...i.....i..i...i..i.i..i.ii..i.....i..i....i..........iiii..........i...ii...i.......ii.i.i.i 100/118
[01:15:53] ......iii.i.....ii
[01:15:53] 
[01:15:53]  finished in 30.240
[01:15:53] travis_fold:end:test_debuginfo

---
[01:26:08] error: no global memory allocator found but one is required; link to std or add #[global_allocator] to a static item that implements the GlobalAlloc trait.
[01:26:08] 
[01:26:08] 
[01:26:08] running 418 tests
[01:26:27] .................F.................................................................................. 100/418
[01:26:55] .................................................................................................... 300/418
[01:27:07] .................................................................................................... 400/418
[01:27:10] ..................
[01:27:10] failures:
[01:27:10] failures:
[01:27:10] 
[01:27:10] ---- boxed.rs - boxed::Box<T>::into_raw_non_null (line 189) stdout ----
[01:27:10] error: use of deprecated item '<std::boxed::Box<T>>::into_raw_non_null': Use `.into()`
[01:27:10]  --> boxed.rs:194:15
[01:27:10]   |
[01:27:10] 7 |     let ptr = Box::into_raw_non_null(x);
[01:27:10]   |
[01:27:10] note: lint level defined here
[01:27:10]  --> boxed.rs:189:9
[01:27:10]   |
---
[01:27:10] 
[01:27:10] error: test failed, to rerun pass '--doc'
[01:27:10] 
[01:27:10] 
[01:27:10] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "-p" "alloc" "--" "--quiet"
[01:27:10] 
[01:27:10] 
[01:27:10] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:27:10] Build completed unsuccessfully in 0:24:06
[01:27:10] Build completed unsuccessfully in 0:24:06
[01:27:10] make: *** [check] Error 1
[01:27:10] Makefile:48: recipe for target 'check' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:36c01f4c
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Tue Jan  8 09:52:20 UTC 2019
---
travis_time:end:1d1bef50:start=1546941141466547234,finish=1546941141524809516,duration=58262282
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:113ca69e
$ 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:1cb0bd00
$ 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)

@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Jan 9, 2019

Travis CI is green but is showing yellow/pending.

Re-syncing...

@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Jan 9, 2019

Oh. Oops, didn't know rfcbot would do that :-/

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Jan 9, 2019

@rfcbot fcp merge

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Jan 9, 2019

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@@ -201,6 +203,7 @@ impl<T: ?Sized> Box<T> {
/// ```
#[unstable(feature = "box_into_raw_non_null", issue = "47336")]
#[inline]
#[rustc_deprecated(reason = "Use `.into()`", since = "1.32.0")]

This comment has been minimized.

@dtolnay

dtolnay Jan 9, 2019

Member

I would prefer not to deprecated this. Inherent associated functions are more discoverable and avoid needing to guide type inference, as you see in the into_raw implementation above.

Box::into_raw_non_null(b).as_ptr()
let p: NonNull<T> = b.into();
p.as_ptr()

This comment has been minimized.

@dwijnand

dwijnand Jan 9, 2019

Member

@SimonSapin suggested this. I'm happy either way.

Do we want one implementation to delegate to the other? And if yes, which way?

This comment has been minimized.

@SimonSapin

SimonSapin Jan 9, 2019

Contributor

@dtolnay Should every single impl of conversion traits have a corresponding inherent method? If not, what makes this one special?

This comment has been minimized.

@dwijnand

dwijnand Jan 9, 2019

Member

Perhaps the very fact that the From/Into traits are type conversions makes them special with regards to ergonomics and type inference. My understanding was that was one of the reasons for having both From and Into, i.e Foo::from avoids result type inference, while bar.into() method-syntax is nicer to use. Being forced by the coherence rules I think it might be worth keeping the associated function.

@@ -479,6 +482,15 @@ impl From<Box<str>> for Box<[u8]> {
}
}

#[allow(incoherent_fundamental_impls)]

This comment has been minimized.

@dtolnay

dtolnay Jan 9, 2019

Member

Please add a comment explaining the implications of this.

This comment has been minimized.

@dwijnand

dwijnand Jan 9, 2019

Member

I don't know what they are. I'm happy to push comments if anyone has any suggestions!

This comment has been minimized.

@Centril

Centril Jan 9, 2019

Contributor

incoherent_fundamental_impls is a C-future-compatibility warning; those are essentially hard errors that have been temporarily lowered into warnings to give people time to migrate. Tho in this case it doesn't seem clearly specified in the issue what the warning actually does. However, there's a PR up that is actually making it into a hard error #49799. If this impl is admitted into stable Rust (i.e. through #[allow(incoherent_fundamental_impls)]) then the warning cannot, AFAIK, be made into a hard error. That seems... bad.

cc @nikomatsakis @rust-lang/wg-traits

Show resolved Hide resolved src/liballoc/boxed.rs Outdated
Show resolved Hide resolved src/liballoc/rc.rs Outdated
@@ -1179,6 +1179,14 @@ impl<T> From<Vec<T>> for Rc<[T]> {
}
}

#[unstable(feature = "rc_into_nonnull", reason = "newly added", issue = "0")]
impl<T: ?Sized> Into<NonNull<T>> for Rc<T> {

This comment has been minimized.

@dtolnay

dtolnay Jan 9, 2019

Member

I would like to add an equivalent inherent function like we have for Box: Rc::into_raw_non_null and Arc::into_raw_non_null.

This comment has been minimized.

@dwijnand

dwijnand Jan 9, 2019

Member

Sure. What is the "raw" for? Also, between the Into impl and the inherent function, should one delegate to the other?

This comment has been minimized.

@dwijnand

dwijnand Jan 9, 2019

Member

I'll wait for #56998 (comment) to be resolved first.

dwijnand added some commits Jan 9, 2019

Mark Rc/Arc into NonNull as insta-stable
Like Simon explained for Box into NonNull.
@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Jan 10, 2019

Yeah... Over on Zulip I've been pointed to RFC 2451 Re-Rebalancing Coherence, which points to #55437 and thus #56145. So if we want to use From and make Box work the same way, we could block this on that PR landing.

Well that PR landed, so maybe this can be implemented using From now?

@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Jan 10, 2019

maybe this can be implemented using From now?

No, it can't.

impl<T: ?Sized> From<Arc<T>> for NonNull<T>

Can't compile in liballoc because T is uncovered. And it can't be implemented with NonNull and From in libcore because Arc isn't available.

@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Jan 15, 2019

@Centril was this triaged at the meeting, or did you change your mind on nominating it?

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 15, 2019

@dwijnand It was. The gist of it is that you cannot do #[allow(incoherent_fundamental_impls)] for reasons mentioned in #56998 (comment). If elaboration is necessary, I'll redirect you to @nikomatsakis. :)

@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Jan 15, 2019

I see! Thanks for the info. I'll reformulate this proposal as Arc/Rc::into_raw_non_null then, and see how that goes.

@dwijnand dwijnand closed this Jan 15, 2019

@dwijnand dwijnand deleted the dwijnand:from-Arc/Rc-to-NonNull branch Jan 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment