| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
- Link from `core::hash` to `HashMap` and `HashSet`
- Link from HashMap and HashSet to the module-level documentation on
when to use the collection
- Link from several collections to Wikipedia articles on the general
concept
|
|
Rollup of 12 pull requests
Successful merges:
- #79423 (Enable smart punctuation)
- #81154 (Improve design of `assert_len`)
- #81235 (Improve suggestion for tuple struct pattern matching errors.)
- #81769 (Suggest `return`ing tail expressions that match return type)
- #81837 (Slight perf improvement on char::to_ascii_lowercase)
- #81969 (Avoid `cfg_if` in `std::os`)
- #81984 (Make WASI's `hard_link` behavior match other platforms.)
- #82091 (use PlaceRef abstractions more consistently)
- #82128 (add diagnostic items for OsString/PathBuf/Owned as well as to_vec on slice)
- #82166 (add s390x-unknown-linux-musl target)
- #82234 (Remove query parameters when skipping search results)
- #82255 (Make `treat_err_as_bug` Option<NonZeroUsize>)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Improve design of `assert_len`
It was discussed in the [tracking issue](https://github.com/rust-lang/rust/issues/76393#issuecomment-761765448) that `assert_len`'s name and usage are confusing. This PR improves them based on a suggestion by ``@scottmcm`` in that issue.
I also improved the documentation to make it clearer when you might want to use this method.
Old example:
```rust
let range = range.assert_len(slice.len());
```
New example:
```rust
let range = range.ensure_subset_of(..slice.len());
```
Fixes #81157
|
|
BTree: move more shared iterator code into navigate.rs
The functions in navigate.rs only exist to support iterators, and these look easier on my eyes if there is a shared `struct` with the recurring pair of handles.
r? `@Mark-Simulacrum`
|
|
BTreeMap: gather and decompose reusable tree fixing functions
This is kind of pushing it as a standalone refactor, probably only useful for #81075 (or similar).
r? `@Mark-Simulacrum`
|
|
|
|
Because child > 0, the two statements are equivalent, but using
saturating_sub and <= yields in faster code. This is most notable in the
binary_heap::bench_into_sorted_vec benchmark, which shows a speedup of
1.26x, which uses sift_down_range internally. The speedup of pop (that
uses sift_down_to_bottom internally) is much less significant as the
sifting method is not called in a loop.
|
|
Document BinaryHeap unsafe functions
`BinaryHeap` contains some private safe functions but that are actually unsafe to call. This PR marks them `unsafe` and documents all the `unsafe` function calls inside them.
While doing this I might also have found a bug: some "SAFETY" comments in `sift_down_range` and `sift_down_to_bottom` are valid only if you assume that `child` doesn't overflow. However it may overflow if `end > isize::MAX` which can be true for ZSTs (but I think only for them). I guess the easiest fix would be to skip any sifting if `mem::size_of::<T> == 0`.
Probably conflicts with #81127 but solving the eventual merge conflict should be pretty easy.
|
|
BTree: share panicky test code & test panic during clear, clone
Bases almost all tests of panic on the same, richer definition, and extends it to cloning to test panic during clone.
r? ```@Mark-Simulacrum```
|
|
|
|
|
|
|
|
Fix typos in BTreeSet::{first, last} docs
map -> set
|
|
|
|
BTreeMap: fix internal comments
Salvaged from #81372
r? `@Mark-Simulacrum`
|
|
BTree: remove outdated traces of coercions
The introduction of `marker::ValMut` (#75200) meant iterators no longer see mutable keys but their code still pretends it does. And settle on the majority style `Some(unsafe {…})` over `unsafe { Some(…) }`.
r? `@Mark-Simulacrum`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
BTreeMap: lightly refactor the split_off implementation
r? `@Mark-Simulacrum`
|
|
BTree: remove Ord bound where it is absent elsewhere
Some btree methods don't really need an Ord bound and don't have one, while some methods that more obviously don't need it, do have one.
An example of the former is `iter`, even though it explicitly exposes the work of the Ord implementation (["sorted by key"](https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.iter) - but I'm not suggesting it should have the Ord bound). An example of the latter is `new`, which doesn't involve any keys whatsoever.
|
|
btree: use Option's unwrap_unchecked()
Now that https://github.com/rust-lang/rust/issues/81383 is available, start using it.
|
|
BTree: fix documentation of unstable public members
As rightfully requested in #62924 & #70530.
r? `@Mark-Simulacrum`
|
|
|
|
|
|
BTreeMap: make Ord bound explicit, compile-test its absence
Most `BTreeMap` and `BTreeSet` members are subject to an `Ord` bound but a fair number of methods are not. To better convey and perhaps later tune the `Ord` bound, make it stand out in individual `where` clauses, instead of once far away at the beginning of an `impl` block. This PR does not introduce or remove any bounds.
Also adds compilation test cases checking that the bound doesn't creep in unintended on the historically unbounded methods.
|
|
This reverts commit 4fef39113a514bb270f5661a82fdba17d3e41dbb.
|
|
Add doc aliases for "delete"
This patch adds doc aliases for "delete". The added aliases are supposed to reference usages `delete` in other programming languages.
- `HashMap::remove`, `BTreeMap::remove` -> `Map#delete` and `delete` keyword in JavaScript.
- `HashSet::remove`, `BTreeSet::remove` -> `Set#delete` in JavaScript.
- `mem::drop` -> `delete` keyword in C++.
- `fs::remove_file`, `fs::remove_dir`, `fs::remove_dir_all`-> `File#delete` in Java, `File#delete` and `Dir#delete` in Ruby.
Before this change, searching for "delete" in documentation returned no results.
|
|
|
|
This patch adds doc aliases for "delete". The added aliases are
supposed to reference usages `delete` in other programming
languages.
- `HashMap::remove`, `BTreeMap::remove` -> `Map#delete` and `delete`
keyword in JavaScript.
- `HashSet::remove`, `BTreeSet::remove` -> `Set#delete` in JavaScript.
- `mem::drop` -> `delete` keyword in C++.
- `fs::remove_file`, `fs::remove_dir`, `fs::remove_dir_all`
-> `File#delete` in Java, `File#delete` and `Dir#delete` in Ruby.
Before this change, searching for "delete" in documentation
returned no results.
|
|
Stabilize raw ref macros
This stabilizes `raw_ref_macros` (https://github.com/rust-lang/rust/issues/73394), which is possible now that https://github.com/rust-lang/rust/issues/74355 is fixed.
However, as I already said in https://github.com/rust-lang/rust/issues/73394#issuecomment-751342185, I am not particularly happy with the current names of the macros. So I propose we also change them, which means I am proposing to stabilize the following in `core::ptr`:
```rust
pub macro const_addr_of($e:expr) {
&raw const $e
}
pub macro mut_addr_of($e:expr) {
&raw mut $e
}
```
The macro name change means we need another round of FCP. Cc `````@rust-lang/libs`````
Fixes #73394
|
|
Now that https://github.com/rust-lang/rust/issues/81383 is available,
start using it.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
|
|
BTreeMap: prevent tree from ever being owned by non-root node
This introduces a new marker type, `Dying`, which is used to note trees which are in the process of deallocation. On such trees, some fields may be in an inconsistent state as we are deallocating the tree. Unfortunately, there's not a great way to express conditional unsafety, so the methods for traversal can cause UB if not invoked correctly, but not marked as such. This is not a regression from the previous state, but rather isolates the destructive methods to solely being called on the dying state.
|
|
Trying to shrink_to greater than capacity should be no-op
Per the discussion in https://github.com/rust-lang/rust/issues/56431, `shrink_to` shouldn't panic if you try to make a vector shrink to a capacity greater than its current capacity.
|
|
BTreeMap: test all borrowing interfaces and test more chaotic order behavior
Inspired by #81169, test what happens if you mess up order of the type with which you search (as opposed to the key type).
r? `@Mark-Simulacrum`
|
|
|
|
|
