Don't recommend ONCE_INIT in std::sync::Once
ONCE_INIT is deprecated, and so suggesting it as not only being on par with, but before `Once::new` is a bad idea.
make File::try_clone produce non-inheritable handles on Windows
~**NOT READY FOR REVIEW.** This PR is currently mainly to trigger CI so that I can see what happens. (Is there a better way to trigger CI?) I don't know whether this change makes sense yet.~ (Edit: @Mark-Simulacrum clarified that CI doesn't currently run on Windows.)
---
File handles shouldn't be inheritable in general.
`std::process::Command` takes care of making them inheritable when child
processes are spawned, and the `CREATE_PROCESS_LOCK` protects against
races in that section on Windows. But `File::try_clone` has been
creating inheritable file descriptors outside of that lock, which could
be leaking into other child processes unintentionally.
See also https://github.com/rust-lang/rust/pull/31069#discussion_r334117665.
- Compatible with Emscripten 1.38.46-upstream or later upstream.
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the old incorrect wasm32 C call ABI with the correct one,
preserving the old one as wasm32_bindgen_compat for wasm-bindgen
compatibility.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
Implement Error::source on IntoStringError + Remove superfluous cause impls
IntoStringError only implemented `Error::cause`, which is deprecated. This implemements `Error::source` instead.
`Error::cause` will still work as before, thanks to the default implementation.
I think this was the only/last `Error` impl in the standard library to have a cause, but not a source.
Split non-CAS atomic support off into target_has_atomic_load_store
This PR implements my proposed changes in https://github.com/rust-lang/rust/issues/32976#issuecomment-518542029 by removing `target_has_atomic = "cas"` and splitting `target_has_atomic` into two separate `cfg`s:
* `target_has_atomic = 8/16/32/64/128`: This indicates the largest width that the target can atomically CAS (which implies support for all atomic operations).
* ` target_has_atomic_load_store = 8/16/32/64/128`: This indicates the largest width that the target can support loading or storing atomically (but may not support CAS).
cc #32976
r? @alexcrichton
IntoStringError only implemented Error::cause, which is
deprecated. This implemements Error::source instead.
Error::cause will still work as before, thanks to the default
implementation.
Mark Path::join as must_use
I've accidentally did `mut_path_buf.jon(a_path);`, expecting this to be an in-place modification. Seems like we can easily warn in such cases?
Added doc about behavior of extend on HashMap
It was unclear what the implementation does when it encounters existing keys. This change makes it clear by documenting the trait impl.
File handles shouldn't be inheritable in general.
`std::process::Command` takes care of making them inheritable when child
processes are spawned, and the `CREATE_PROCESS_LOCK` protects against
races in that section on Windows. But `File::try_clone` has been
creating inheritable file descriptors outside of that lock, which could
be leaking into other child processes unintentionally.
See also https://github.com/rust-lang/rust/pull/31069#discussion_r334117665.
Implement (HashMap) Entry::insert as per #60142
Implementation of `Entry::insert` as per @SimonSapin's comment on #60142. This requires a patch to hashbrown:
```diff
diff --git a/src/rustc_entry.rs b/src/rustc_entry.rs
index fefa5c3..7de8300 100644
--- a/src/rustc_entry.rs
+++ b/src/rustc_entry.rs
@@ -546,6 +546,32 @@ impl<'a, K, V> RustcVacantEntry<'a, K, V> {
let bucket = self.table.insert_no_grow(self.hash, (self.key, value));
unsafe { &mut bucket.as_mut().1 }
}
+
+ /// Sets the value of the entry with the RustcVacantEntry's key,
+ /// and returns a RustcOccupiedEntry.
+ ///
+ /// # Examples
+ ///
+ /// ```
+ /// use hashbrown::HashMap;
+ /// use hashbrown::hash_map::RustcEntry;
+ ///
+ /// let mut map: HashMap<&str, u32> = HashMap::new();
+ ///
+ /// if let RustcEntry::Vacant(v) = map.rustc_entry("poneyland") {
+ /// let o = v.insert_and_return(37);
+ /// assert_eq!(o.get(), &37);
+ /// }
+ /// ```
+ #[inline]
+ pub fn insert_and_return(self, value: V) -> RustcOccupiedEntry<'a, K, V> {
+ let bucket = self.table.insert_no_grow(self.hash, (self.key, value));
+ RustcOccupiedEntry {
+ key: None,
+ elem: bucket,
+ table: self.table
+ }
+ }
}
impl<K, V> IterMut<'_, K, V> {
```
This is also only an implementation for HashMap. I tried implementing for BTreeMap, but I don't really understand BTreeMap's internals and require more guidance on implementing the equivalent `VacantEntry::insert_and_return` such that it returns an `OccupiedEntry`. Notably, following the original PR's modifications I end up needing a `Handle<NodeRef<marker::Mut<'_>, _, _, marker::LeafOrInternal>, _>` while I only have a `Handle<NodeRef<marker::Mut<'_>, _, _, marker::Internal>, _>` and don't know how to proceed.
(To be clear, I'm not asking for guidance right now; I'd be happy getting only the HashMap implementation — the subject of this PR — reviewed and ready, and leave the BTreeMap implementation for a latter PR.)
Revert #63649 - "Upgrade Emscripten targets to use upstream LLVM backend"
This change caused the runtime of the linux-asmjs builder to nearly double from 2+ hours to about 4 hours, which happens to be the bors timeout. (It made it in barely under 4 hours when it was merged.) This is causing timeouts on all new changes.
This reverts commit 7870050796e5904a0fc85ecbe6fa6dde1cfe0c91, reversing
changes made to 2e7244807a7878f6eca3eb7d97ae9b413aa49014.
Fix typo on `now()` comments
Fix typo, update words, and remove some redundant word.
Also rustfmt on the rest of the file (hope this is okay :)
revival of #61433
r? @kennytm
std: Reduce checks for `feature = "backtrace"`
This is a stylistic change to libstd to reduce the number of checks of
`feature = "backtrace"` now that we unconditionally depend on the
`backtrace` crate and rely on it having an empty implementation.
otherwise.
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the incorrect wasm32 C call ABI with the old asmjs
version, which is correct for both wasm32 and JS.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Temporarily makes Emscripten targets use panic=abort by default
because supporting unwinding will require an LLVM patch.
Stabilize todo macro
The `todo!` macro is just another name for `unimplemented!`.
Tracking issue: https://github.com/rust-lang/rust/issues/59277
This PR needs a FCP to merge.
r? @withoutboats
This commit improves obligation errors for async/await:
```
note: future does not implement `std::marker::Send` because this value is used across an
await
--> $DIR/issue-64130-non-send-future-diags.rs:15:5
|
LL | let g = x.lock().unwrap();
| - has type `std::sync::MutexGuard<'_, u32>`
LL | baz().await;
| ^^^^^^^^^^^ await occurs here, with `g` maybe used later
LL | }
| - `g` is later dropped here
```
Signed-off-by: David Wood <david@davidtw.co>
Docs: slice elements are equidistant
Recently, someone asked why `[char]` and `str` are not interchangeable, and I explained that in a slice, the elements must be laid out equidistantly, whereas the chars in a `str` are stored compactly regardless their size. However I couldn't find this documented anywhere, so here's a small addition of this fact.
Fuchsia exit codes don't follow the convention of libc::WEXITSTATUS et
al, and they are 64 bits instead of 32 bits. This gives Fuchsia its own
representation of ExitStatus.
Additionally, the zircon syscall structs were out of date, causing us to
see bogus return codes.