This commit is an implementation of [RFC 592][r592] and [RFC 840][r840]. These
two RFCs tweak the behavior of `CString` and add a new `CStr` unsized slice type
to the module.
[r592]: https://github.com/rust-lang/rfcs/blob/master/text/0592-c-str-deref.md
[r840]: https://github.com/rust-lang/rfcs/blob/master/text/0840-no-panic-in-c-string.md
The new `CStr` type is only constructable via two methods:
1. By `deref`'ing from a `CString`
2. Unsafely via `CStr::from_ptr`
The purpose of `CStr` is to be an unsized type which is a thin pointer to a
`libc::c_char` (currently it is a fat pointer slice due to implementation
limitations). Strings from C can be safely represented with a `CStr` and an
appropriate lifetime as well. Consumers of `&CString` should now consume `&CStr`
instead to allow producers to pass in C-originating strings instead of just
Rust-allocated strings.
A new constructor was added to `CString`, `new`, which takes `T: IntoBytes`
instead of separate `from_slice` and `from_vec` methods (both have been
deprecated in favor of `new`). The `new` method returns a `Result` instead of
panicking. The error variant contains the relevant information about where the
error happened and bytes (if present). Conversions are provided to the
`io::Error` and `old_io::IoError` types via the `FromError` trait which
translate to `InvalidInput`.
This is a breaking change due to the modification of existing `#[unstable]` APIs
and new deprecation, and more detailed information can be found in the two RFCs.
Notable breakage includes:
* All construction of `CString` now needs to use `new` and handle the outgoing
`Result`.
* Usage of `CString` as a byte slice now explicitly needs a `.as_bytes()` call.
* The `as_slice*` methods have been removed in favor of just having the
`as_bytes*` methods.
Closes#22469Closes#22470
[breaking-change]
This is a more introductory document, suitable for Part II. The arcane details move to an "Advanced macros" chapter in Part III.
Conflicts:
src/doc/trpl/macros.md
This redux of CONTRIBUTING.md adds in more information, including
subsuming both compliment-bugreport.md and Note-development-policy
in the wiki.
I only glanced at the broad TOC of Note-development-policy, and did
not use the text as the basis for the re-write. This will then address
the last outstanding part of #5831.
The first commit adds a short note which I believe will reduce worries in people who work with closures very often and read the Rust book for their first time.
The second commit consists solely of tiny typo fixes. In some cases, I changed "logical" quotations like
She said, "I like programming".
to
She said, "I like programming."
because the latter seems to be the prevalent style in the book.
The Rust Programming Language book has no explanation of what `i32` actually means. I have added an explanation for the first time the reader encounters this type.
@steveklabnik Trying out the Glossary idea.
Added the paragraph about 'complicated words' because I think it would be useful to those contributing to the book. Maybe this should not be here
The book in "hello-world" tells that there are configs for some programs and gives a link to main repo's src/etc. Actually, these configs moved to separate repos some days ago. This PR adds a markdown file with links and moves "hello-world" link about editors to point directly to this new file.
This redux of CONTRIBUTING.md adds in more information, including
subsuming both compliment-bugreport.md and Note-development-policy
in the wiki.
I only glanced at the broad TOC of Note-development-policy, and did
not use the text as the basis for the re-write. This will then address
the last outstanding part of #5831.
