Move Duration to libcore (and remove deprecated Duration::span)

[SimonSapin]

The Duration::span removal will hit stable in 1.7 at the soonest, while 1.6 already has the deprecation warning.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[brson]

cc @rust-lang/libs

[sfackler]

Travis failure: https://travis-ci.org/rust-lang/rust/builds/99159735#L6416

I'm tentatively on board with this, but since libcore is stable now, we'll have to make sure we'll never want to add functionality that libcore can't support.

[huonw]

It seems like it would be nice to have Duration unstable in core but stable in std, but I suspect this isn't currently possible.

[SimonSapin]

Pushed a fix, make check-stage1-bench passes locally.

[SimonSapin]

I'm tentatively on board with this, but since libcore is stable now, we'll have to make sure we'll never want to add functionality that libcore can't support.

This (having different set of functionality in core vs std for the same type) is not specific to Duration, and I expect we’ll encounter the same problem for other types in the future. The answer is extension traits, possibly in the prelude.

For str and char we’ve done this "backwards": libcore has StrExt and CharExt traits in its prelude with a subset of the functionality, while inherent method definitions are in libcollections and librustc_unicode. But this coherence-rules-bending trick only works for primitive types, right?

[SimonSapin]

I think Travis is stuck in a loop. I pushed hours ago and it’s now showing "Elapsed time 11 min 19 sec", but it was 20 minutes or so earlier.

[bors]

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

[aturon]

@SimonSapin

But this coherence-rules-bending trick only works for primitive types, right?

It's applicable to whatever types we like, but not something anyone has much of an appetite for doing. We did it for primitive types primarily because you hit them so early when learning Rust that extension traits seemed really problematic.

I agree with @huonw that ideally we'd have it unstable in core and stable in std, so that we can take our time on the stabilization aspect. @SimonSapin, would you mind trying that?

[SimonSapin]

Re stability: sounds reasonable. I’ve pushed a commit that I think does this.

[aturon]

@SimonSapin Can you add a test for stability in compile-fail?

[alexcrichton]

I think that lots of stability portions in the compiler don't expect a stable type with an unstable parent so it may not work out in terms of ensuring all usage through libcore is gated. For example all the method usage will be stable in libcore, it's just the module itself that's unstable. (which I forget how it affects the stability checking of a path like core::time::Duration)

[bors]

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

[aturon]

I'm going to flag for libs team discussion.

[alexcrichton]

The libs team discussed this PR during triage today, and the conclusion was to close this for now. Currently we think that moving a type from std to libcore needs motivation aside from "it can be done", as there are stabilization ramifications to moving into libcore rather than sticking with std (e.g. it's much harder to add functionality that requires std).

It was also brought up that this may not be too useful as the only member of core::time, which is where a motivating example would be more convincing here. Thanks for the PR though @SimonSapin!