std: Stabilize the `ffi` module by alexcrichton · Pull Request #22975 · rust-lang/rust

alexcrichton · 2015-03-02T20:58:07Z

The two main sub-modules, c_str and os_str, have now had some time to bake
in the standard library. This commits performs a sweep over the modules adding
various stability tags.

The following APIs are now marked #[stable]

OsString
OsStr
OsString::from_string
OsString::from_str
OsString::new
OsString::into_string
OsString::push (renamed from push_os_str, added an AsOsStr bound)
various trait implementations for OsString
OsStr::from_str
OsStr::to_str
OsStr::to_string_lossy
OsStr::to_os_string
various trait implementations for OsStr
CString
CStr
NulError
CString::new - this API's implementation may change as a result of
RFC: improve CString construction methods rfcs#912 but the usage of CString::new(thing) looks like it is
unlikely to change. Additionally, the IntoBytes bound is also likely to
change but the set of implementors for the trait will not change (despite the
trait perhaps being renamed).
CString::from_vec_unchecked
CString::as_bytes
CString::as_bytes_with_nul
NulError::nul_position
NulError::into_vec
CStr::from_ptr
CStr::to_bytes
CStr::to_bytes_with_nul
various trait implementations for CStr

The following APIs remain #[unstable]

OsStr*Ext traits remain unstable as the organization of os::platform is
uncertain still and the traits may change location.
AsOsStr remains unstable as generic conversion traits are likely to be
rethought soon.

The following APIs were deprecated

OsString::push_os_str is now called push and takes T: AsOsStr instead (a
superset of the previous functionality).

[breaking-change]

rust-highfive · 2015-03-02T20:58:18Z

r? @huonw

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

alexcrichton · 2015-03-02T20:58:43Z

r? @aturon

alexcrichton · 2015-03-02T20:59:06Z

cc @mzabaluev, rust-lang/rfcs#912

mzabaluev · 2015-03-02T21:11:50Z

In rust-lang/rfcs#912 it was proposed to change (and perhaps rename) IntoBytes to convert directly to CString. Other than that, the stabilization looks OK.

nagisa · 2015-03-02T21:44:00Z

Stable reexport?

While not currently recognized by the compiler I've found it useful to see reexports tagged with stability attributes for rustdoc when it doesn't inline documentation and perhaps just helpful when reading code. It doesn't currently serve any semantic purpose though.

bors · 2015-03-03T14:23:31Z

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

alexcrichton · 2015-03-03T17:15:13Z

@mzabaluev thanks for taking a look! Due to the unstable-ness of IntoBytes we should be fine renaming it backwards compatibly. I was considering doing so in this PR but I opted not to wait for the resolution of your RFC.

alexcrichton · 2015-03-04T21:27:35Z

Ah and I just realized that I forgot to decide on CStr::as_ptr (cc #16035). I forget the outcome of our discussions around this @aturon, but would you be ok stabilizing for now?

aturon · 2015-03-05T04:29:54Z

We're moving away from public tuple structs in std; this should probably be a normal struct with accessors.

Oops nevermind.

(I always forget that, unlike enum variants, the pub doesn't automatically extend to tuple components...)

aturon · 2015-03-05T05:51:50Z

@alexcrichtonas_ptr remains a real footgun, but we decided that it's not feasible to land the infrastructure needed to do better for 1.0. You were planning to work on the design and eventually submit an RFC.

Meanwhile, it seemed ok to stabilize as_ptr as-is, with an eventual planned deprecation.

I wonder if type ascription would change the tradeoff at all? In particular, we were worried about cases involving null to-from Option conversion and triggering coercions. Ascription could help with ergonomics tehre.

In any case, I think it's fine to stabilize this for now, because any reference-based replacement would likely want a different name and lead to deprecation of this method. If that happens before 1.0, all the better.

Otherwise, r=me.

alexcrichton · 2015-03-05T20:14:30Z

@bors: r=aturon 6ab4938

The two main sub-modules, `c_str` and `os_str`, have now had some time to bake in the standard library. This commits performs a sweep over the modules adding various stability tags. The following APIs are now marked `#[stable]` * `OsString` * `OsStr` * `OsString::from_string` * `OsString::from_str` * `OsString::new` * `OsString::into_string` * `OsString::push` (renamed from `push_os_str`, added an `AsOsStr` bound) * various trait implementations for `OsString` * `OsStr::from_str` * `OsStr::to_str` * `OsStr::to_string_lossy` * `OsStr::to_os_string` * various trait implementations for `OsStr` * `CString` * `CStr` * `NulError` * `CString::new` - this API's implementation may change as a result of rust-lang/rfcs#912 but the usage of `CString::new(thing)` looks like it is unlikely to change. Additionally, the `IntoBytes` bound is also likely to change but the set of implementors for the trait will not change (despite the trait perhaps being renamed). * `CString::from_vec_unchecked` * `CString::as_bytes` * `CString::as_bytes_with_nul` * `NulError::nul_position` * `NulError::into_vec` * `CStr::from_ptr` * `CStr::as_ptr` * `CStr::to_bytes` * `CStr::to_bytes_with_nul` * various trait implementations for `CStr` The following APIs remain `#[unstable]` * `OsStr*Ext` traits remain unstable as the organization of `os::platform` is uncertain still and the traits may change location. * `AsOsStr` remains unstable as generic conversion traits are likely to be rethought soon. The following APIs were deprecated * `OsString::push_os_str` is now called `push` and takes `T: AsOsStr` instead (a superset of the previous functionality).

alexcrichton · 2015-03-05T22:57:29Z

@bors: r=aturon 628f5d2

Conflicts: src/librustc_trans/back/link.rs src/librustc_trans/lib.rs

rust-highfive assigned huonw Mar 2, 2015

aturon mentioned this pull request Mar 2, 2015
Stabilization for 1.0-beta #22500
Closed
91 tasks

rust-highfive assigned aturon and unassigned huonw Mar 2, 2015

alexcrichton force-pushed the stabilize-ffi branch from 397e56a to 328e6acCompare March 2, 2015 20:59

nagisa reviewed Mar 2, 2015
View reviewed changes

alexcrichton force-pushed the stabilize-ffi branch from 328e6ac to f01b62eCompare March 3, 2015 17:14

aturon reviewed Mar 5, 2015
View reviewed changes

alexcrichton force-pushed the stabilize-ffi branch from f01b62e to 6ab4938Compare March 5, 2015 20:14

alexcrichton force-pushed the stabilize-ffi branch from 6ab4938 to 628f5d2Compare March 5, 2015 22:57

alexcrichton added a commit to alexcrichton/rust that referenced this pull request Mar 6, 2015
rollup merge ofrust-lang#22975: alexcrichton/stabilize-ffi
2bd02ca
Conflicts: src/librustc_trans/back/link.rs src/librustc_trans/lib.rs

bors merged commit 628f5d2 into rust-lang:masterMar 7, 2015

alexcrichton deleted the stabilize-ffi branch March 7, 2015 06:13

Uh oh!

Uh oh!

Conversation

alexcrichton commented Mar 2, 2015

Uh oh!

rust-highfive commented Mar 2, 2015

Uh oh!

alexcrichton commented Mar 2, 2015

Uh oh!

alexcrichton commented Mar 2, 2015

Uh oh!

mzabaluev commented Mar 2, 2015

Uh oh!

nagisaMar 2, 2015

Choose a reason for hiding this comment

Uh oh!

alexcrichtonMar 2, 2015

Choose a reason for hiding this comment

Uh oh!

bors commented Mar 3, 2015

Uh oh!

alexcrichton commented Mar 3, 2015

Uh oh!

alexcrichton commented Mar 4, 2015

Uh oh!

aturonMar 5, 2015

Choose a reason for hiding this comment

Uh oh!

aturonMar 5, 2015

Choose a reason for hiding this comment

Uh oh!

aturonMar 5, 2015

Choose a reason for hiding this comment

Uh oh!

aturon commented Mar 5, 2015

Uh oh!

alexcrichton commented Mar 5, 2015

Uh oh!

alexcrichton commented Mar 5, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants