| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Improve doc wording for retain on some collections
I found the documentation wording on the various retain methods on many collections to be unusual.
I tried to invert the relation by switching `such that` with `for which` .
|
|
|
|
This updates the standard library's documentation to use the new syntax. The
documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.
A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #92902 (Improve the documentation of drain members)
- #93658 (Stabilize `#[cfg(panic = "...")]`)
- #93954 (rustdoc-json: buffer output)
- #93979 (Add debug assertions to validate NUL terminator in c strings)
- #93990 (pre #89862 cleanup)
- #94006 (Use a `Field` in `ConstraintCategory::ClosureUpvar`)
- #94086 (Fix ScalarInt to char conversion)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
Remove unnecessary bounds for some Hash{Map,Set} methods
This PR moves `HashMap::{into_keys,into_values,retain}` and `HashSet::retain` from `impl` blocks with `K: Eq + Hash, S: BuildHasher` into the blocks without them. It doesn't seem to me there is any reason these methods need to be bounded by that. This change brings `HashMap::{into_keys,into_values}` on par with `HashMap::{keys,values,values_mut}` which are not bounded either.
|
|
Stabilise entry_insert
This stabilises `HashMap:Entry::insert_entry` etc. Tracking issue #65225. It will need an FCP.
This was implemented in #64656 two years ago.
This PR includes the rename and change discussed in https://github.com/rust-lang/rust/issues/65225#issuecomment-910652430, happy to split if needed.
|
|
|
|
|
|
JosephTLyons:update-HashMap-and-BTreeMap-documentation, r=yaahc
Update documentation to use `from()` to initialize `HashMap`s and `BTreeMap`s
As of Rust 1.56, `HashMap` and `BTreeMap` both have associated `from()` functions. I think using these in the documentation cleans things up a bit. It allows us to remove some of the `mut`s and avoids the Initialize-Then-Modify anti-pattern.
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Félix Saparelli <felix@passcod.name>
|
|
|
|
|
|
|
|
|
|
r=joshtriplett
Add #[must_use] to core and std constructors
Parent issue: #89692
r? ``@joshtriplett``
|
|
|
|
|
|
|
|
|
|
2229: Mark insignificant dtor in stdlib
I looked at all public [stdlib Drop implementations](https://doc.rust-lang.org/stable/std/ops/trait.Drop.html#implementors) and categorized them into Insigificant/Maybe/Significant Drop.
Reasons are noted here: https://docs.google.com/spreadsheets/d/19edb9r5lo2UqMrCOVjV0fwcSdS-R7qvKNL76q7tO8VA/edit#gid=1838773501
One thing missing from this PR is tagging HashMap as insigificant destructor as that needs some discussion.
r? `@Mark-Simulacrum`
cc `@nikomatsakis`
|
|
|
|
|
|
Fix typos “a”→“an”
Fix typos in comments; found using a regex to find some easy instance of incorrect usage of a vs. an.
While automation was used to find these, every change was checked manually.
Changes in submodules get separate PRs:
* https://github.com/rust-lang/stdarch/pull/1201
* https://github.com/rust-lang/cargo/pull/9821
* https://github.com/rust-lang/miri/pull/1874
* https://github.com/rust-lang/rls/pull/1746
* https://github.com/rust-analyzer/rust-analyzer/pull/9984
_folks @ rust-analyzer are fast at merging…_
* https://github.com/rust-analyzer/rust-analyzer/pull/9985
* https://github.com/rust-analyzer/rust-analyzer/pull/9987
* https://github.com/rust-analyzer/rust-analyzer/pull/9989
_For `clippy`, I don’t know if the changes should better better be moved to a PR to the original repo._
<hr>
This has some overlap with #88226, but neither is a strict superset of the other.
If you want multiple commits, I can split it up; in that case, make sure to suggest a criterion for splitting.
|
|
Add doctests for HashMap's into_values and into_keys methods
Fixes #87591
|
|
|
|
|
|
Stabilize Vec<T>::shrink_to
This PR stabilizes `shrink_to` feature and closes the corresponding issue. The second point was addressed already, and no `panic!` should occur.
Closes #56431.
|
|
|
|
Hide allocator details from TryReserveError
I think there's [no need for TryReserveError to carry detailed information](https://github.com/rust-lang/rust/issues/48043#issuecomment-825139280), but I wouldn't want that issue to delay stabilization of the `try_reserve` feature.
So I'm proposing to stabilize `try_reserve` with a `TryReserveError` as an opaque structure, and if needed, expose error details later.
This PR moves the `enum` to an unstable inner `TryReserveErrorKind` that lives under a separate feature flag. `TryReserveErrorKind` could possibly be left as an implementation detail forever, and the `TryReserveError` get methods such as `allocation_size() -> Option<usize>` or `layout() -> Option<Layout>` instead, or the details could be dropped completely to make try-reserve errors just a unit struct, and thus smaller and cheaper.
|
|
r=Mark-Simulacrum
Ignore comments in tidy-filelength
Ref https://github.com/rust-lang/rust/issues/60302#issuecomment-652402127
|
|
Use hashbrown's `extend_reserve()` in `HashMap`
When we added `extend_reserve()` to our implementation of `Extend` for `HashMap`, hashbrown didn't have a version we could use. Now that hashbrown has added it, we should use its version instead of implementing it ourself.
|
|
|
|
Stabilize `impl From<[(K, V); N]> for HashMap` (and friends)
In addition to allowing HashMap to participate in Into/From conversion, this adds the long-requested ability to use constructor-like syntax for initializing a HashMap:
```rust
let map = HashMap::from([
(1, 2),
(3, 4),
(5, 6)
]);
```
This addition is highly motivated by existing precedence, e.g. it is already possible to similarly construct a Vec from a fixed-size array:
```rust
let vec = Vec::from([1, 2, 3]);
```
...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa):
```rust
let vec = Vec::from([(1, 2)]);
let map: HashMap<_, _> = vec.into_iter().collect();
let vec: Vec<(_, _)> = map.into_iter().collect();
```
...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)):
```rust
let arr = [(1, 2)];
let map: HashMap<_, _> = std::array::IntoIter::new(arr).collect();
```
Therefore this addition seems like a no-brainer.
As for any impl, this would be insta-stable.
|
|
|
|
|
|
Document iteration order of `retain` functions
For `HashSet` and `HashMap`, this simply copies the comment from
`BinaryHeap::retain`.
For `BTreeSet` and `BTreeMap`, this adds an additional guarantee that
wasn't previously documented. I think that because these data structures
are inherently ordered and other functions guarantee ordered iteration,
it makes sense to provide this guarantee for `retain` as well.
|
|
|
|
|
|
|
|
For `HashSet` and `HashMap`, this simply copies the comment from
`BinaryHeap::retain`.
For `BTreeSet` and `BTreeMap`, this adds an additional guarantee that
wasn't previously documented. I think that because these data structures
are inherently ordered and other functions guarantee ordered iteration,
it makes sense to provide this guarantee for `retain` as well.
|
|
|
