-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
std: Stabilize the ffi
module
#22975
Conversation
r? @huonw (rust_highfive has picked a reviewer for you, use r? to override) |
r? @aturon |
397e56a
to
328e6ac
Compare
In rust-lang/rfcs#912 it was proposed to change (and perhaps rename) |
|
||
pub use self::c_str::{CString, CStr, NulError, IntoBytes}; | ||
#[stable(feature = "rust1", since = "1.0.0")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stable reexport?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
☔ The latest upstream changes (presumably #22995) made this pull request unmergeable. Please resolve the merge conflicts. |
328e6ac
to
f01b62e
Compare
@mzabaluev thanks for taking a look! Due to the unstable-ness of |
inner: [libc::c_char] | ||
} | ||
|
||
/// An error returned from `CString::new` to indicate that a nul byte was found | ||
/// in the vector provided. | ||
#[derive(Clone, PartialEq, Debug)] | ||
#[stable(feature = "rust1", since = "1.0.0")] | ||
pub struct NulError(usize, Vec<u8>); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're moving away from public tuple structs in std
; this should probably be a normal struct with accessors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops nevermind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I always forget that, unlike enum variants, the pub doesn't automatically extend to tuple components...)
@alexcrichton Meanwhile, it seemed ok to stabilize I wonder if type ascription would change the tradeoff at all? In particular, we were worried about cases involving null to-from 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. |
f01b62e
to
6ab4938
Compare
@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).
6ab4938
to
628f5d2
Compare
Conflicts: src/librustc_trans/back/link.rs src/librustc_trans/lib.rs
The two main sub-modules,
c_str
andos_str
, have now had some time to bakein 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 frompush_os_str
, added anAsOsStr
bound)OsString
OsStr::from_str
OsStr::to_str
OsStr::to_string_lossy
OsStr::to_os_string
OsStr
CString
CStr
NulError
CString::new
- this API's implementation may change as a result ofRFC: improve CString construction methods rfcs#912 but the usage of
CString::new(thing)
looks like it isunlikely to change. Additionally, the
IntoBytes
bound is also likely tochange 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
CStr
The following APIs remain
#[unstable]
OsStr*Ext
traits remain unstable as the organization ofos::platform
isuncertain still and the traits may change location.
AsOsStr
remains unstable as generic conversion traits are likely to berethought soon.
The following APIs were deprecated
OsString::push_os_str
is now calledpush
and takesT: AsOsStr
instead (asuperset of the previous functionality).
[breaking-change]