| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Move the length check to before using `index` with `ptr::add` to prevent
an out of bounds pointer from being formed.
Fixes #122760
|
|
|
|
SeqCst is unnecessary here.
|
|
Stabilize associated type bounds (RFC 2289)
This PR stabilizes associated type bounds, which were laid out in [RFC 2289]. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested `impl Trait` or broken into several `where` clauses.
### What are we stabilizing?
We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. `T: Trait<Assoc: Bounds...>`. See [RFC 2289] for motivation.
In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info).
Associated type bounds are stabilized in four positions:
* **`where` clauses (and APIT)** - This is equivalent to breaking up the bound into two (or more) `where` clauses. For example, `where T: Trait<Assoc: Bound>` is equivalent to `where T: Trait, <T as Trait>::Assoc: Bound`.
* **Supertraits** - Similar to above, `trait CopyIterator: Iterator<Item: Copy> {}`. This is almost equivalent to breaking up the bound into two (or more) `where` clauses; however, the bound on the associated item is implied whenever the trait is used. See #112573/#112629.
* **Associated type item bounds** - This allows constraining the *nested* rigid projections that are associated with a trait's associated types. e.g. `trait Trait { type Assoc: Trait2<Assoc2: Copy>; }`.
* **opaque item bounds (RPIT, TAIT)** - This allows constraining associated types that are associated with the opaque without having to *name* the opaque. For example, `impl Iterator<Item: Copy>` defines an iterator whose item is `Copy` without having to actually name that item bound.
The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in #120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds.
### How does this differ from the RFC?
Compared to the RFC, the current implementation *always* desugars associated type bounds to sets of `ty::Clause`s internally. Specifically, it does *not* introduce a position-dependent desugaring as laid out in [RFC 2289], and in particular:
* It does *not* desugar to anonymous associated items in associated type item bounds.
* It does *not* desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds.
This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in #120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example:
* Conditionally lowering to nested `impl Trait` in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: https://github.com/rust-lang/rust/pull/120752#issuecomment-1979412531.
* Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in `dyn` types.
This last point motivates why this PR is *not* stabilizing support for associated type bounds in `dyn` types, e.g, `dyn Assoc<Item: Bound>`. Why? Because `dyn` types need to have *concrete* types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write `impl Trait` themselves. See #120719.
### Implementation history:
Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out--
* #57428
* #108063
* #110512
* #112629
* #120719
* #120584
Closes #52662
[RFC 2289]: https://rust-lang.github.io/rfcs/2289-associated-type-bounds.html
|
|
Improve wording of `Vec::swap_remove`
This improve the wording for `Vec::swap_remove`.
|
|
|
|
|
|
|
|
|
|
The dead_code lint was previously eroneously missing those.
Since this lint bug has been fixed, the unused fields need
to be removed.
|
|
RawVec::into_box: avoid unnecessary intermediate reference
Fixes the problem described [here](https://github.com/rust-lang/miri/issues/3341#issuecomment-1987207195).
|
|
Add slice::try_range
This adds a fallible version of the unstable `slice::range` (tracking: #76393) which is highly requested in the tracking issue.
Hoping this can slide by without an ACP (since the feature is already being tracked), but let me know otherwise.
|
|
|
|
Add std::ffi::c_str module
ACP: rust-lang/libs-team#134
`std::ffi` docs before change:
`std::ffi` docs after change:
(note: I'm omitting the `c_int`, etc. stuff from the screenshots since it's the same in both. this doesn't just delete those types)
|
|
Vec::try_with_capacity
Related to #91913
Implements try_with_capacity for `Vec`, `VecDeque`, and `String`. I can follow it up with more collections if desired.
`Vec::try_with_capacity()` is functionally equivalent to the current stable:
```rust
let mut v = Vec::new();
v.try_reserve_exact(n)?
```
However, `try_reserve` calls non-inlined `finish_grow`, which requires old and new `Layout`, and is designed to reallocate memory. There is benefit to using `try_with_capacity`, besides syntax convenience, because it generates much smaller code at the call site with a direct call to the allocator. There's codegen test included.
It's also a very desirable functionality for users of `no_global_oom_handling` (Rust-for-Linux), since it makes a very commonly used function available in that environment (`with_capacity` is used much more frequently than all `(try_)reserve(_exact)`).
|
|
|
|
|
|
Specifically, when an override doesn't just forward to an inner type,
document the behavior and that it's preferred over simply assigning
a clone of source. Also, change instances where the second parameter is
"other" to "source".
|
|
Add `#[inline]` to `BTreeMap::new` constructor
This PR add the `#[inline]` attribute to `BTreeMap::new` constructor as to make it eligible for inlining.
<details>
For some context: I was profiling `rustc --check-cfg` with callgrind and due to the way we currently setup all the targets and we end-up calling `BTreeMap::new` multiple times for (nearly) all the targets. Adding the `#[inline]` attribute reduced the number of instructions needed.
</details>
|
|
|
|
|
|
only set noalias on Box with the global allocator
As discovered in https://github.com/rust-lang/miri/issues/3341, `noalias` and custom allocators don't go well together.
rustc can now check whether a Box uses the global allocator. This replaces the previous ad-hoc and rather unprincipled check for a zero-sized allocator.
This is the rustc part of fixing that; Miri will also need a patch.
|
|
const_eval_select: make it safe but be careful with what we expose on stable for now
As this is all still nightly-only I think `````@rust-lang/wg-const-eval````` can do that without involving t-lang.
r? `````@oli-obk`````
Cc `````@Nilstrieb````` -- the updated version of your RFC would basically say that we can remove these comments about not making behavior differences visible in stable `const fn`
|
|
|
|
Clarify/add `must_use` message for Rc/Arc/Weak::into_raw.
The current `#[must_use]` messages for `{sync,rc}::Weak::into_raw` ("`self` will be dropped if the result is not used") are misleading, as `self` is consumed and will *not* be dropped.
This PR changes their `#[must_use]` message to the same as `Arc::into_raw`'s[ current `#[must_use]` message](https://github.com/rust-lang/rust/blob/d5735645753e990a72446094f703df9b5e421555/library/alloc/src/sync.rs#L1482) ("losing the pointer will leak memory"), and also adds it to `Rc::into_raw`, which is not currently `#[must_use]`.
|
|
Add vector time complexity
Added time complexity for `Vec` methods `push`, `push_within_capacity`, `pop`, and `insert`.
<details>
<summary> Reference images </summary>
</details>
I followed a convention to use `#Time complexity` that I found in [the `BinaryHeap` documentation](https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html#time-complexity-1). Looking through the rest of standard library collections, there is not a consistent way to handle this.
[`Vec::swap_remove`](https://doc.rust-lang.org/std/vec/struct.Vec.html#method.swap_remove) does not have a dedicated section for time complexity but does list it.
[`VecDeque::rotate_left`](https://doc.rust-lang.org/std/collections/struct.VecDeque.html#complexity) uses a `#complexity` heading.
|
|
r=cuviper
Add an example to demonstrate how Rc::into_inner works
This PR adds an example to Rc::into_inner, since it didn't have one previously.
|
|
Preserve same vtable pointer when cloning raw waker, to fix Waker::will_wake
Fixes #121600.
As `@jkarneges` identified in https://github.com/rust-lang/rust/issues/121600#issuecomment-1963041051, the issue is two different const promotions produce two statics at different addresses, which may or may not later be deduplicated by the linker (in this case not).
Prior to #119863, the content of the statics was compared, and they were equal. After, the address of the statics are compared and they are not equal.
It is documented that `will_wake` _"works on a best-effort basis, and may return false even when the Wakers would awaken the same task"_ so this PR fixes a quality-of-implementation issue, not a correctness issue.
|
|
for now
|
|
Code changes in raw_vec require blessing UI tests every time
|
|
#91913
|
|
|
|
|
|
Have `String` use `SliceIndex` impls from `str`
This PR simplifies the implementation of `Index` and `IndexMut` on `String`, and in the process enables indexing `String` by any user types that implement `SliceIndex<str>`.
Similar to #47832
r? libs
Not sure if this warrants a crater run.
|
|
|
|
|
|
|
|
|
|
order
|
|
argument order
|
|
|
|
Use `addr_of!`
As per https://github.com/rust-lang/rust/pull/121303#discussion_r1500954662
|
|
Those libraries are build with `-C panic=unwind` and is expected to
be linkable to `-C panic=abort` library. To ensure unsoundness
compiler needs to prevent a `C-unwind` call to exist, as doing so may leak
foreign exceptions into `-C panic=abort`.
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #120742 (mark `min_exhaustive_patterns` as complete)
- #121470 (Don't ICE on anonymous struct in enum variant)
- #121492 (coverage: Rename `is_closure` to `is_hole`)
- #121495 (remove repetitive words)
- #121498 (Make QNX/NTO specific "timespec capping" public to crate::sys)
- #121510 (lint-overflowing-ops: unify cases and remove redundancy)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use generic `NonZero` everywhere in `library`.
Tracking issue: https://github.com/rust-lang/rust/issues/120257
Use generic `NonZero` everywhere (except stable examples).
r? `@dtolnay`
|
|
Signed-off-by: cui fliter <imcusg@gmail.com>
|
|
|
|
Help with common API confusion, like asking for `push` when the data structure really has `append`.
```
error[E0599]: no method named `size` found for struct `Vec<{integer}>` in the current scope
--> $DIR/rustc_confusables_std_cases.rs:17:7
|
LL | x.size();
| ^^^^
|
help: you might have meant to use `len`
|
LL | x.len();
| ~~~
help: there is a method with a similar name
|
LL | x.resize();
| ~~~~~~
```
#59450
|
