Rollup of 7 pull requests
Successful merges:
- #69041 (proc_macro: Stabilize `Span::resolved_at` and `Span::located_at`)
- #69813 (Implement BitOr and BitOrAssign for the NonZero integer types)
- #70712 (stabilize BTreeMap::remove_entry)
- #71168 (Deprecate `{Box,Rc,Arc}::into_raw_non_null`)
- #71544 (Replace filter_map().next() calls with find_map())
- #71545 (Fix comment in docstring example for Error::kind)
- #71548 (Add missing Send and Sync impls for linked list Cursor and CursorMut.)
Failed merges:
r? @ghost
Add missing Send and Sync impls for linked list Cursor and CursorMut.
Someone pointed out these to me, and i think it's indeed reasonable to add those impl.
r? @Amanieu
Take a single root node in range_search
The unsafe code can be justified within range_search, as it makes sure to not
overlap the returned references, but from the callers perspective it's an
entirely safe algorithm and there's no need for the caller to know about the
duplication.
cc @ssomers
r? @Amanieu
Add BinaryHeap::retain as suggested in #42849
This PR implements retain for BinaryHeap as suggested in #42849.
This is my first PR for Rust, so please let me know if I should be doing anything differently, thanks!
The unsafe code can be justified within range_search, as it makes sure to not
overlap the returned references, but from the callers perspective it's an
entirely safe algorithm and there's no need for the caller to know about the
duplication.
This adds a couple of more diagnostic items to be used in Clippy.
I chose these particular ones because they were the types which we seem
to check for the most in Clippy. I'm not sure if the
`cfg_attr(not(test))` is needed, but it was also used for `Vec` and a
few other types.
Address concerns of weak-into-raw
This should address the standing concerns in https://github.com/rust-lang/rust/issues/60728#issuecomment-612525616.
I've still left the ability to create a new dangling pointer from `null`, as I feel like this is the natural behaviour to expect, but I'm fine removing that too. I've modified the documentation to allow the `as_ptr` or `into_ptr` to return whatever garbage in case of a dangling pointer. I've also removed the guarantee to be able to do `from_raw(as_ptr)` from the documentation (but it would still work right now).
I've renamed the method and added implementations for `Rc`/`Arc`.
I've also tried if I can just „enable“ unsized types. I believe the current interface is compatible with them. But the inner implementation will be a bit challenging ‒ I can't use the `data_offset` as is used by `Rc` or `Arc` because it AFAIK „touches“ (creates a reference to) the live value of `T` ‒ and in case of `Weak`, it might be completely bogus or already dead ‒ so that would be UB.
`./x.py test tidy` is completely mad on my own system all over the code base :-(. I'll just hope it goes through CI, or will fix as necessary.
Is it OK if I ask @Amanieu for review, as the concerns are from you?
~r @Amanieu
big-O notation: parenthesis for function calls, explicit multiplication
I saw `O(n m log n)` in the docs and found that really hard to parse. In particular, I don't think we should use blank space as syntax for *both* multiplication and function calls, that is just confusing.
This PR makes both multiplication and function calls explicit using Rust-like syntax. If you prefer, I can also leave one of them implicit, but I believe explicit is better here.
While I was at it I also added backticks consistently.
Dogfood or_patterns in the standard library
We can start using `or_patterns` in the standard library as a step toward stabilization.
cc #54883 @Centril
Minor fixes to doc comments of 'VecDeque'
1. Changed descriptions of `fn get` & `fn get_mut`.
Since both of these functions are returning references, and not the owned value, I thought the doc comments could be fixed to be consistent with doc comments of `fn front` & `fn front_mut`.
2. Other changes are minor fixes or additions for clarification.
Thank you for taking a look :)
1. Changed descriptions of `fn get` & `fn get_mut`.
Since both of these functions are returning references, and not the owned value, I thought the doc comments could be fixed to be consistent with doc comments of `fn front` & `fn front_mut`.
2. Other changes are minor fixes or additions for clarification.
Thank you for taking a look :)
simplify `vec!` macro
Simplify `vec!` macro by replacing 2 following branches:
- `($($x:expr),*) => (...)`
- `($($x:expr,)*) => (...)`
with one:
- `($($x:expr),* $(,)?) => (...)`
This is a minor change, however, this will make the documentation cleaner
* Rename Weak::as_raw to Weak::as_ptr for consistency with some other
types.
* The as_ptr for a dangling Weak pointer might return whatever garbage
(and takes that advantage to avoid a conditional).
* Don't guarantee to be able to do `Weak::from_raw(weak.as_ptr())` (even
though it'll still work fine).
Add or_insert_with_key to Entry of HashMap/BTreeMap
Going along with `or_insert_with`, `or_insert_with_key` provides the `Entry`'s key to the lambda, avoiding the need to either clone the key or the need to reimplement this body of this method from scratch each time.
This is useful when the initial value for a map entry is derived from the key. For example, the introductory Rust book has an example Cacher struct that takes an expensive-to-compute lambda and then can, given an argument to the lambda, produce either the cached result or execute the lambda.
---
I'm fairly new to Rust, so any optimizations, corrections to types, better names, better documentation, or whatever else would be appreciated. I'd like to thank Arnavion on freenode for helping me to implement a very similar method when I found that `or_insert_with_key` was unavailable.
As a somewhat-related note, this implements https://github.com/rust-lang/rfcs/issues/1202 from 2015, so if this pull request is accepted, that should be closed.
Going along with or_insert_with, or_insert_with_key provides the
Entry's key to the lambda, avoiding the need to either clone the
key or the need to reimplement this body of this method from
scratch each time.
This is useful when the initial value for a map entry is derived
from the key. For example, the introductory Rust book has an
example Cacher struct that takes an expensive-to-compute lambda and
then can, given an argument to the lambda, produce either the
cached result or execute the lambda.
Rearrange BTreeMap::into_iter to match range_mut.
r? @Mark-Simulacrum
I wondered why you catered for the optional root differently in `into_iter` than in `range_mut`.
Replace "rc"/"arc" lang items with Rc/Arc diagnostic items.
`Rc`/`Arc` should have no special semantics, so it seems appropriate for them to not be lang items.
r? @matthewjasper
