Bump version to 1.47
This also bumps to a more recent rustfmt version, just to keep us relatively up to date (though almost nothing has changed in rustfmt we use beyond bumps to the parser infra). No formatting changes as a result of this.
r? @pietroalbini
Add VecDeque::range* methods
This patch adds `VecDeque::range` and `VecDeque::range_mut` to provide
iterators over a sub-range of a `VecDeque`. This behavior can be
emulated with `skip` and `take`, but directly providing a `Range` is
more ergonomic. This also partially makes up for `VecDeque`'s lack of
`SliceIndex` support.
Move A|Rc::as_ptr from feature(weak_into_raw) to feature(rc_as_ptr)
These were stabilized alongside the Weak versions, but having `feature = "weak_.."` on a fn definition for the non-weak pointers is potentially very misleading, especially in a review context where the impl header may not be immediately visible.
r? @RalfJung
@bors rollup=always
This patch adds `VecDeque::range` and `VecDeque::range_mut` to provide
iterators over a sub-range of a `VecDeque`. This behavior can be
emulated with `skip` and `take`, but directly providing a `Range` is
more ergonomic. This also partially makes up for `VecDeque`'s lack of
`SliceIndex` support.
Remove unnecessary release from Arc::try_unwrap
The thread that recovers the unique access to Arc inner value (e.g., drop
when ref-count strong reaches zero, successful try_unwrap), ensures that
other operations on Arc inner value happened before by synchronizing
with release operations performed when decrementing the reference counter.
When try_unwrap succeeds, the current thread recovers the unique access
to Arc inner value, so release is unnecessary.
r? @Amanieu
added .collect() into String from Box<str>
I have not created an rfc, because i felt like this is a very minor change.
i have just set a random feature name and rust version as stability attribute, i expect to have to change that, i just don't know what the policy on that is. all guides i could find focused on contributing to the compiler, not contributing to the standard library.
drawbacks: more code in the standard library, could be replaced with specialization: base-implementation for AsRef\<str> and specialization for String and Cow. i can write that code if ppl want it.
advantages: using "real strings" i.e. Box\<str> is as ergonomic as string slices (&str) and string buffers (String) with iterators.
The thread that recovers the unique access to Arc inner value (e.g., drop
when ref-count strong reaches zero, successful try_unwrap), ensures that
other operations on Arc inner value happened before by synchronizing
with release operations performed when decrementing the reference counter.
When try_unwrap succeeds, the current thread recovers the unique access
to Arc inner value, so release is unnecessary.
Use &raw in A|Rc::as_ptr
This PR uses `&raw` for offsetting `*mut [A]RcInner<T> -> *mut T`.
Additionally, this updates the implementation of `Weak::as_ptr` to support unsized `T`, though it does not yet relax the bounds of `Weak::as_ptr`/`into_raw`/`from_raw` to accept unsized `T`.
to feature(rc_as_ptr)
These were stabilized alongside the Weak versions,
but having `feature = "weak_.."` on a fn definition
for the non-weak pointers is potentially very confusing.
Update Box::from_raw example to generalize better
I know very little about rust, so I saw the example here
```
use std::alloc::{alloc, Layout};
unsafe {
let ptr = alloc(Layout:🆕:<i32>()) as *mut i32;
*ptr = 5;
let x = Box::from_raw(ptr);
}
```
and tried to generalize it by writing,
```
let layout = Layout:🆕:<T>();
let new_obj = unsafe {
let ptr = alloc(layout) as *mut T;
*ptr = obj;
Box::from_raw(ptr)
};
```
for some more complicated `T`, which ended up crashing with SIGSEGV,
because it tried to `drop_in_place` the previous object in `ptr` which is
of course garbage. I think that changing this example to use `.write` instead
would be a good idea to suggest the correct generalization. It is also more
consistent with other documentation items in this file, which use `.write`.
I also added a comment to explain it, but I'm not too attached to that,
and can see it being too verbose in this place.
Shortcuts for min/max on double-ended BTreeMap/BTreeSet iterators
Closes#59947: a performance tweak that might benefit some. Optimizes `min` and `max ` on all btree double-ended iterators that do not drop, i.e. the iterators created by:
- `BTreeMap::iter`
- `BTreeMap::iter_mut`
- `BTreeMap::keys` and `BTreeSet::iter`
- `BTreeMap::range` and `BTreeSet::range`
- `BTreeMap::range_mut`
Also in these (currently) single-ended iterators, but obviously for `min` only:
- `BTreeSet::difference`
- `BTreeSet::intersection`
- `BTreeSet::symmetric_difference`
- `BTreeSet::union`
Did not do this in iterators created by `into_iter` to preserve drop order, as outlined in #62316.
Did not do this in iterators created by `drain_filter`, possibly to preserve drop order, possibly to preserve predicate invocation, mostly to not have to think about it too hard (I guess maybe it wouldn't be a change for `min`, which is the only shortcut possible in this single-ended iterator).
`improper_ctypes_definitions` lint
Addresses #19834, #66220, and #66373.
This PR takes another attempt at #65134 (reverted in #66378). Instead of modifying the existing `improper_ctypes` lint to consider `extern "C" fn` definitions in addition to `extern "C" {}` declarations, this PR adds a new lint - `improper_ctypes_definitions` - which only applies to `extern "C" fn` definitions.
In addition, the `improper_ctype_definitions` lint differs from `improper_ctypes` by considering `*T` and `&T` (where `T: Sized`) FFI-safe (addressing #66220).
There wasn't a clear consensus in #66220 (where the issues with #65134 were primarily discussed) on the approach to take, but there has [been some discussion in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2366220.20improper_ctypes.20definitions.20vs.20declarations/near/198903086). I fully expect that we'll want to iterate on this before landing.
cc @varkor + @shepmaster (from #19834) @hanna-kruppe (active in discussing #66220), @SimonSapin (#65134 caused problems for Servo, want to make sure that this PR doesn't)
This commit adds a new lint - `improper_ctypes_definitions` - which
functions identically to `improper_ctypes`, but on `extern "C" fn`
definitions (as opposed to `improper_ctypes`'s `extern "C" {}`
declarations).
Signed-off-by: David Wood <david@davidtw.co>
