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

Make iter::Empty<T> Send and Sync for any T #57682

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
6 participants
@xfix
Copy link
Contributor

xfix commented Jan 16, 2019

Just because it can be. Likely nobody will be using that property of iter::empty, but at the same time, there is no reason to not allow it.

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Jan 16, 2019

r? @dtolnay

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

@dtolnay
Copy link
Member

dtolnay left a comment

Thanks!

@dtolnay

This comment has been minimized.

Copy link
Member

dtolnay commented Jan 16, 2019

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 16, 2019

📌 Commit f973f37 has been approved by dtolnay

@rust-highfive

This comment was marked as off-topic.

Copy link
Collaborator

rust-highfive commented Jan 16, 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:192f2f09:start=1547680212157290755,finish=1547680213099119402,duration=941828647
$ 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:44] 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:04:44] expected success, got: exit code: 101
[00:04:44] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap build
[00:04:44] Build completed unsuccessfully in 0:00:30
[00:04:44] Makefile:18: recipe for target 'all' failed
[00:04:44] make: *** [all] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:12529736
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Wed Jan 16 23:15:10 UTC 2019
---
travis_time:end:0bd7c920:start=1547680511264511371,finish=1547680511270661973,duration=6150602
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:284d70bc
$ 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

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)

@xfix

This comment has been minimized.

Copy link
Contributor Author

xfix commented Jan 16, 2019

Hm, I guess it cannot be done currently, as for const fn, a PhantomData<fn() -> T> is considered to be a function pointer, and I don't feel like putting unsafe impl<T> Send for Empty<T> {}.

@dtolnay

This comment has been minimized.

Copy link
Member

dtolnay commented Jan 16, 2019

@bors r-

@dtolnay

This comment has been minimized.

Copy link
Member

dtolnay commented Jan 16, 2019

error: function pointers in const fn are unstable
   --> src/libcore/iter/sources.rs:277:11
    |
277 |     Empty(marker::PhantomData)
    |           ^^^^^^^^^^^^^^^^^^^

Strange. I guess an unsafe impl would be the way to go.

@xfix

This comment has been minimized.

Copy link
Contributor Author

xfix commented Jan 16, 2019

I wonder if special casing PhantomData in const fn check would make sense, but doing so would be way out of scope of this pull request.

@dtolnay

This comment has been minimized.

Copy link
Member

dtolnay commented Jan 16, 2019

function pointers in const fn are unstable

It sounds like this has been implemented already but not stabilized yet. Adding #![feature(const_fn)] makes the same error disappear in the playground. But libcore/lib.rs already has #![feature(const_fn)]:

#![feature(const_fn)]

Any suggestions @oli-obk?

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 17, 2019

@dtolnay For #[stable] items in the standard library we impose an additional restriction that it must conform to min_const_fn and if it doesn't we emit an error. Having #![feature(const_fn)] does not affect that. You can see this by enabling #![feature(staged_api)].

The recourse you have here is to use something other than fn(T) to get the covariance and auto trait behavior you want. I think &'static T should work here but I would double check.

@dtolnay

This comment has been minimized.

Copy link
Member

dtolnay commented Jan 17, 2019

&'static T would impose T: 'static, and is only Send if T is Sync. playground

@xfix -- I would go ahead and add unsafe impls. playground

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 17, 2019

@dtolnay oh right; yeah, unsafe impls it is :)

@xfix xfix force-pushed the xfix:patch-14 branch from f973f37 to 3b49f7e Jan 17, 2019

@xfix

This comment has been minimized.

Copy link
Contributor Author

xfix commented Jan 17, 2019

Or, I have another idea how to do it without unsafe.

@xfix xfix force-pushed the xfix:patch-14 branch from 3b49f7e to 5b60b2a Jan 17, 2019

@xfix

This comment has been minimized.

Copy link
Contributor Author

xfix commented Jan 17, 2019

Arguably abusing a bug, but IMO PhantomData<fn() -> T> should be allowed, even in minimal const fn.

@xfix xfix force-pushed the xfix:patch-14 branch from 5b60b2a to 4ead708 Jan 17, 2019

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 17, 2019

@xfix That's not a bug; an intentional choice was made in min_const_fn to not recurse into data types.

@xfix

This comment has been minimized.

Copy link
Contributor Author

xfix commented Jan 17, 2019

@Centril I don't know, compiler rejecting PhantomData<fn() -> T> but being fine with PhantomData<PhantomFnWorkaround<T>> sounds inconsistent to me. Like, I understand why the rule is what it is - it's necessary for instance for Vec::<fn()>::new() to be const fn, as on the lowest levels, Vec<T> is using PhantomData<T>. And this is fine, except I don't understand why reject PhantomData<fn() -> T> in const fn subset.

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 17, 2019

@xfix It's an intentional inconsistency ;) (see #53604 (review), #53604 (comment)) and doesn't really have to do with Vec::<fn()>::new(). Anyways, I'm fine with the solution here.

@rust-highfive

This comment was marked as resolved.

Copy link
Collaborator

rust-highfive commented Jan 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:2aec0584:start=1547718904558684084,finish=1547719057761738216,duration=153203054132
$ 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:07:59] tidy error: /checkout/src/libcore/iter/sources.rs:203: trailing whitespace
[00:08:00] some tidy checks failed
[00:08:00] 
[00:08:00] 
[00:08:00] 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:08:00] 
[00:08:00] 
[00:08:00] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:08:00] Build completed unsuccessfully in 0:00:47
[00:08:00] Build completed unsuccessfully in 0:00:47
[00:08:00] Makefile:69: recipe for target 'tidy' failed
[00:08:00] make: *** [tidy] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:03f5c250
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Thu Jan 17 10:05:47 UTC 2019
---
travis_time:end:119cc1da:start=1547719548841383169,finish=1547719548846462407,duration=5079238
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:02df44fc
$ 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:067f673a
travis_time:start:067f673a
$ 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:02b5a05c
$ 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/libcore/iter/sources.rs Outdated

@xfix xfix force-pushed the xfix:patch-14 branch from 4ead708 to 313c628 Jan 17, 2019

@dtolnay
Copy link
Member

dtolnay left a comment

This is a little crazy for my taste. I would prefer to see plain old unsafe impls over this.

Or, add a more readable and better tested mechanism internal to libcore for establishing variance and auto traits. By standardizing on something like this over PhantomData<T> / PhantomData<fn() -> T> / PhantomData<PhantomFnWorkaround<T>>, the variance and auto trait impls become clearly visible during code reviews and we are more likely to catch when they are wrong for some type.

pub struct Empty<T>(phantom_data![T, Covariant + AlwaysSendSync]);

We would want to support any combination of {Covariant, Contravariant, Invariant} × {AlwaysSendSync, NeverSendSync, InheritSendSync}.

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 25, 2019

Ping from triage @xfix, can you update to the unsafe impls as requested?

@Dylan-DPC

This comment has been minimized.

Copy link
Member

Dylan-DPC commented Feb 4, 2019

ping from triage @xfix any updates on this?

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