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.)
Ignore `ExprKind::DropTemps` for some ref suggestions
Introduce `Expr::peel_drop_temps()` to ignore `ExprKind::DropTemps` for suggestions that depend on the `ExprKind` for accuracy.
typeck: prohibit foreign statics w/ generics
Fixes#65035 and fixes#65025.
This PR modifies resolve to disallow foreign statics that have
generics.
`improper_ctypes` is not written to support type parameters, as these
are normally disallowed before the lint is run. Thus, type parameters in
foreign statics must be prohibited before the lint.
The only other case where this *could* have occured is in functions,
but typeck prohibits this with a "foreign items may not have type
parameters" error - a similar error did not exist for statics, because
statics cannot have type parameters, but they can use any
type parameters that are in scope (which isn't the case for functions).
Warn if include macro fails to include entire file
This currently introduces an error, mainly because that was just simpler, and I'm not entirely certain if we can introduce a lint without an RFC and such.
This is primarily to get feedback on the approach and overall aim -- in particular, do we think this is helpful? If so, we probably will need lang-team sign off and decide if it should be an error (as currently introduced by this PR), a lint, or a warning.
r? @petrochenkov
cc https://github.com/rust-lang/rust/issues/35560
Updates LLVM to pick up the cherry-picked support for correctly
handling exception handling with aggregates passed by value. This will
be necessary to continue to support Emscripten's exception handling
once we switch using Emscripten's LLVM backend. See #63649.
This commit modifies resolve to disallow foreign statics that use
parent generics.
`improper_ctypes` is not written to support type parameters, as these
are normally disallowed before the lint is run. Thus, type parameters in
foreign statics must be prohibited before the lint.
The only other case where this *could* have occured is in functions,
but typeck prohibits this with a "foreign items may not have type
parameters" error - a similar error did not exist for statics, because
statics cannot have type parameters, but they can use any
type parameters that are in scope (which isn't the case for functions).
Signed-off-by: David Wood <david@davidtw.co>
Rollup of 8 pull requests
Successful merges:
- #64404 (Add long error explanation for E0495)
- #64918 (Add long error explanation for E0551)
- #65102 (Disable stack probe when thread sanitizer is enabled)
- #65120 (Correctly estimate the required space for string in `StyledBuffer::prepend`)
- #65145 (When suggesting assoc function with type params, include turbofish)
- #65162 (Remove loaded_from_cache map from DepGraph)
- #65176 (Remove query-related macros)
- #65179 (Add long error explanation for E0567)
Failed merges:
r? @ghost
Remove query-related macros
The query system has a few macros that only have one or two call sites, and I find they hurt readability. This PR removes them.
r? @michaelwoerister
Remove loaded_from_cache map from DepGraph
It's now unused, even with -Zquery-dep-graph
From https://github.com/rust-lang/rust/pull/63756/files#r316039379 -- it'll simplify that PR to get this landed separately so we can just remove some of the code that it touches.
r? @Zoxc or @michaelwoerister
Disable stack probe when thread sanitizer is enabled
When thread sanitizer instrumentation is enabled during compilation of
stack probe function, the function will be miscompiled and trigger
segmentation fault at runtime. Disable stack probes when tsan is
enabled.
