Merge pull request #4073 from tgross35/backport-rutabega

[0.2] Backports

Author: tgross35

CONTRIBUTING.md

@@ -3,12 +3,43 @@
 Welcome! If you are reading this document, it means you are interested in
 contributing to the `libc` crate.
 
-## v0.2 changes
+## v1.0 Roadmap
 
-If you want to add your changes to v0.2, please submit them to the `libc-0.2`
-branch. If you want to add any breaking changes, it should be submitted to the
-main branch, which has changes for v0.3. We will support and make a new release
-for v0.2 until we make the first release of v0.3.
+`libc` has two active branches: `main` and `libc-0.2`. `main` is for active
+development of the upcoming v1.0 release, and should be the target of all pull
+requests. `libc-0.2` is for updates to the currently released version.
+
+If a pull request to `main` is a good candidate for inclusion in an `0.2.x`
+release, include `@rustbot label stable-nominated` in a comment to propose this.
+Good candidates will usually meet the following:
+
+1. The included changes are non-breaking.
+2. The change applies cleanly to both branches.
+3. There is a usecase that justifies inclusion in a stable release (all
+   additions should always have a usecase, hopefully).
+
+Once a `stable-nominated` PR targeting `main` has merged, it can be cherry
+picked to the `libc-0.2` branch. A maintainer will likely do these cherry picks
+in a batch.
+
+Alternatively, you can start this process yourself by creating a new branch
+based on `libc-0.2` and running `git cherry-pick -xe commit-sha-on-main`
+(`git
+cherry-pick -xe start-sha^..end-sha` if a range of commits is needed).
+`git` will automatically add the "cherry picked from commit" note, but try to
+add a backport note so the original PR gets crosslinked:
+
+```
+# ... original commit message ...
+
+(backport <https://github.com/rust-lang/libc/pull/1234>)             # add manually
+(cherry picked from commit 104b6a4ae31c726814c36318dc718470cc96e167) # added by git
+```
+
+Once the cherry-pick is complete, open a PR targeting `libc-0.2`.
+
+See the [tracking issue](https://github.com/rust-lang/libc/issues/3248) for
+details.
 
 ## Adding an API
 
@@ -51,7 +82,7 @@ With that in mind, the steps for adding a new API are:
 5. Wait for a merge!
 
 <sup>1</sup>: Note that this list has nothing to do with any Unix or Posix
-standard, it's just a list shared between all OSs that declare `#[cfg(unix)]`.
+standard, it's just a list shared among all OSs that declare `#[cfg(unix)]`.
 
 ## Test before you commit
 
@@ -79,13 +110,12 @@ are:
   - The `note` field should have a reason to deprecate and a tracking issue to
     call for comments (e.g., "We consider removing this as the upstream removed
     it. If you're using it, please comment on #XXX").
-
 2. If we don't see any concerns for a while, do the change actually.
 
 ## Supported target policy
 
 When Rust removes a support for a target, the libc crate also may remove the
-support anytime.
+support at any time.
 
 ## Releasing your change to crates.io
 

README.md

@@ -20,14 +20,16 @@ More detailed information about the design of this library can be found in its
 [rfc]: https://github.com/rust-lang/rfcs/blob/HEAD/text/1291-promote-libc.md
 [windows-sys]: https://docs.rs/windows-sys
 
-## v0.3 Roadmap
+## v1.0 Roadmap
 
-The main branch is now for v0.3 which has some breaking changes.
+Currently, `libc` has two active branches: `main` for the upcoming v1.0 release,
+and `libc-0.2` for the currently published version. By default all pull requests
+should target `main`; once reviewed, they can be cherry picked to the `libc-0.2`
+branch if needed.
 
-For v0.2, please submit PRs to the `libc-0.2` branch instead. We will stop
-making new v0.2 releases once we release v0.3 on crates.io.
+We will stop making new v0.2 releases once v1.0 is released.
 
-See the [tracking issue](https://github.com/rust-lang/libc/issues/3248) for
+See the section in [CONTRIBUTING.md](CONTRIBUTING.md#v10-roadmap) for more
 details.
 
 ## Usage
@@ -51,14 +53,13 @@ libc = "0.2"
   use Rust >= 1.62, this feature is implicitly enabled. Otherwise it requires a
   nightly rustc.
 
-* **deprecated**: `use_std` is deprecated, and is equivalent to `std`.
-
 ## Rust version support
 
 The minimum supported Rust toolchain version is currently **Rust 1.63**.
 
 Increases to the MSRV are allowed to change without a major (i.e. semver-
-breaking) release in order to avoid a ripple effect in the ecosystem.
+breaking) release in order to avoid a ripple effect in the ecosystem. A policy
+for when this may change is a work in progress.
 
 `libc` may continue to compile with Rust versions older than the current MSRV
 but this is not guaranteed.

src/teeos/mod.rs

@@ -48,7 +48,7 @@ pub type ssize_t = isize;
 
 pub type pid_t = c_int;
 
-// aarch64 specifc
+// aarch64 specific
 pub type c_char = u8;
 
 pub type wchar_t = u32;
@@ -61,9 +61,9 @@ pub type c_ulong = u64;
 pub struct _CLongDouble(pub u128);
 
 // long double in C means A float point value, which has 128bit length.
-// but some bit maybe not used, so the really length of long double could be 80(x86) or 128(power pc/IEEE)
+// but some bit maybe not used, so the real length of long double could be 80(x86) or 128(power pc/IEEE)
 // this is different from f128(not stable and not included default) in Rust, so we use u128 for FFI(Rust to C).
-// this is unstable and will couse to memfault/data abort.
+// this is unstable and will cause to memfault/data abort.
 pub type c_longdouble = _CLongDouble;
 
 pub type pthread_t = c_ulong;

src/unix/haiku/native.rs

@@ -1300,7 +1300,7 @@ extern "C" {
     pub fn find_path_for_path_etc(
         path: *const ::c_char,
         dependency: *const ::c_char,
-        architectur: *const ::c_char,
+        architecture: *const ::c_char,
         baseDirectory: path_base_directory,
         subPath: *const ::c_char,
         flags: u32,