Faithfully represent the contents of the CString and CStr in their Debug
impl, by treating them as byte strings with our default escaping to
ascii representation.
Add impl Debug for Cstr.
Fixes#26964.
This allows CString and CStr to be used with the Cow type,
which is extremely useful when interfacing with C libraries
that make extensive use of C-style strings.
This was motivated by http://www.evanmiller.org/a-taste-of-rust.html.
A common problem when working with FFI right now is converting from raw
C strings into `&str` or `String`. Right now you're required to say
something like
let cstr = unsafe { CStr::from_ptr(ptr) };
let result = str::from_utf8(cstr.to_bytes());
This is slightly awkward, and is not particularly intuitive for people
who haven't used the ffi module before. We can do a bit better by
providing some convenience methods on CStr:
fn to_str(&self) -> Result<&str, str::Utf8Error>
fn to_string_lossy(&self) -> Cow<str>
This will make it immediately apparent to new users of CStr how to get a
string from a raw C string, so they can say:
let s = unsafe { CStr::from_ptr(ptr).to_string_lossy() };
A common problem when working with FFI right now is converting from raw
C strings into `&str` or `String`. Right now you're required to say
something like
let cstr = unsafe { CStr::from_ptr(ptr) };
let result = str::from_utf8(cstr.to_bytes());
This is slightly awkward, and is not particularly intuitive for people
who haven't used the ffi module before. We can do a bit better by
providing some convenience methods on CStr:
fn to_str(&self) -> Result<&str, str::Utf8Error>
fn to_string_lossy(&self) -> Cow<str>
This will make it immediately apparent to new users of CStr how to get a
string from a raw C string, so they can say:
let s = unsafe { CStr::from_ptr(ptr).to_string_lossy() };
It looks like `from_vec` was subsumed by new at some point,
but the documentation still refers to it as `from_vec`.
This updates the documentation for `from_vec_unchecked`
so that it properly says that it's the unchecked version of `new`.
Also, from_vec_unchecked requires a actual Vec<u8> while
new can take anything that is Into<Vec<u8>>, so I also
mention that in the documentation.
Since this is documentation:
r? @steveklabnik
It looks like `from_vec` was subsumed by new at some point,
but the documentation still refers to it as `from_vec`.
This updates the documentation for `from_vec_unchecked`
so that it properly says that it's the unchecked version of `new`.
Also, from_vec_unchecked requires a actual Vec<u8> while
new can take anything that is Into<Vec<u8>>, so I also
mention that in the documentation.
This commit stabilizes a few remaining bits of the `io::Error` type:
* The `Error::new` method is now stable. The last `detail` parameter was removed
and the second `desc` parameter was generalized to `E: Into<Box<Error>>` to
allow creating an I/O error from any form of error. Currently there is no form
of downcasting, but this will be added in time.
* An implementation of `From<&str> for Box<Error>` was added to liballoc to
allow construction of errors from raw strings.
* The `Error::raw_os_error` method was stabilized as-is.
* Trait impls for `Clone`, `Eq`, and `PartialEq` were removed from `Error` as it
is not possible to use them with trait objects.
This is a breaking change due to the modification of the `new` method as well as
the removal of the trait implementations for the `Error` type.
[breaking-change]
This commit cleans out a large amount of deprecated APIs from the standard
library and some of the facade crates as well, updating all users in the
compiler and in tests as it goes along.
* Marks `#[stable]` the contents of the `std::convert` module.
* Added methods `PathBuf::as_path`, `OsString::as_os_str`,
`String::as_str`, `Vec::{as_slice, as_mut_slice}`.
* Deprecates `OsStr::from_str` in favor of a new, stable, and more
general `OsStr::new`.
* Adds unstable methods `OsString::from_bytes` and `OsStr::{to_bytes,
to_cstring}` for ergonomic FFI usage.
[breaking-change]
This removes the FromError trait, since it can now be expressed using
the new convert::Into trait. All implementations of FromError<E> where
changed to From<E>, and `try!` was changed to use From::from instead.
Because this removes FromError, it is a breaking change, but fixing it
simply requires changing the words `FromError` to `From`, and
`from_error` to `from`.
[breaking-change]
This commit revises `path` and `os_str` to use blanket impls for `From`
on reference types. This both cuts down on the number of required impls,
and means that you can pass through e.g. `T: AsRef<OsStr>` to
`PathBuf::from` without an intermediate call to `as_ref`.
It also makes a FIXME note for later generalizing the blanket impls for
`AsRef` and `AsMut` to use `Deref`/`DerefMut`, once it is possible to do
so.
This is a [breaking-change]. When indexing a generic map (hashmap, etc) using the `[]` operator, it is now necessary to borrow explicitly, so change `map[key]` to `map[&key]` (consistent with the `get` routine). However, indexing of string-valued maps with constant strings can now be written `map["abc"]`.
r? @japaric
cc @aturon @Gankro
This commit:
* Introduces `std::convert`, providing an implementation of
RFC 529.
* Deprecates the `AsPath`, `AsOsStr`, and `IntoBytes` traits, all
in favor of the corresponding generic conversion traits.
Consequently, various IO APIs now take `AsRef<Path>` rather than
`AsPath`, and so on. Since the types provided by `std` implement both
traits, this should cause relatively little breakage.
* Deprecates many `from_foo` constructors in favor of `from`.
* Changes `PathBuf::new` to take no argument (creating an empty buffer,
as per convention). The previous behavior is now available as
`PathBuf::from`.
* De-stabilizes `IntoCow`. It's not clear whether we need this separate trait.
Closes#22751Closes#14433
[breaking-change]
This commit stabilizes essentially all of the new `std::path` API. The
API itself is changed in a couple of ways (which brings it in closer
alignment with the RFC):
* `.` components are now normalized away, unless they appear at the
start of a path. This in turn effects the semantics of e.g. asking for
the file name of `foo/` or `foo/.`, both of which yield `Some("foo")`
now. This semantics is what the original RFC specified, and is also
desirable given early experience rolling out the new API.
* The `parent` method is now `without_file` and succeeds if, and only
if, `file_name` is `Some(_)`. That means, in particular, that it fails
for a path like `foo/../`. This change affects `pop` as well.
In addition, the `old_path` module is now deprecated.
[breaking-change]
r? @alexcrichton
This commit stabilizes essentially all of the new `std::path` API. The
API itself is changed in a couple of ways (which brings it in closer
alignment with the RFC):
* `.` components are now normalized away, unless they appear at the
start of a path. This in turn effects the semantics of e.g. asking for
the file name of `foo/` or `foo/.`, both of which yield `Some("foo")`
now. This semantics is what the original RFC specified, and is also
desirable given early experience rolling out the new API.
* The `parent` function now succeeds if, and only if, the path has at
least one non-root/prefix component. This change affects `pop` as
well.
* The `Prefix` component now involves a separate `PrefixComponent`
struct, to better allow for keeping both parsed and unparsed prefix data.
In addition, the `old_path` module is now deprecated.
Closes#23264
[breaking-change]
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).
* The lint visitor's visit_ty method did not recurse, and had a
reference to the now closed#10894
* The newly enabled recursion has only affected the `deprectated` lint
which now detects uses of deprecated items in trait impls and
function return types
* Renamed some references to `CowString` and `CowVec` to `Cow<str>` and
`Cow<[T]>`, respectively, which appear outside of the crate which
defines them
* Replaced a few instances of `InvariantType<T>` with
`PhantomData<Cell<T>>`
* Disabled the `deprecated` lint in several places that
reference/implement traits on deprecated items which will get cleaned
up in the future
* Disabled the `exceeding_bitshifts` lint for
compile-fail/huge-array-simple test so it doesn't shadow the expected
error on 32bit systems
* Unfortunately, this means that if a library declares
`#![deny(deprecated)]` and marks anything as deprecated, it will have
to disable the lint for any uses of said item, e.g. any impl the now
deprecated item
For any library that denies deprecated items but has deprecated items
of its own, this is a [breaking-change]
