Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 10 pull requests #122011

Closed
wants to merge 33 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Takashiidobe and others added 30 commits February 16, 2024 20:21
Copying is O(n)—not the memory allocation
Code changes in raw_vec require blessing UI tests every time
When encountering trait bound errors that satisfy some heuristics that
tell us that the relevant trait for the user comes from the root
obligation and not the current obligation, we use the root predicate for
the main message.

This allows to talk about "X doesn't implement Pattern<'_>" over the
most specific case that just happened to fail, like  "char doesn't
implement Fn(&mut char)" in
`tests/ui/traits/suggest-dereferences/root-obligation.rs`

The heuristics are:

 - the type of the leaf predicate is (roughly) the same as the type
   from the root predicate, as a proxy for "we care about the root"
 - the leaf trait and the root trait are different, so as to avoid
   talking about `&mut T: Trait` and instead remain talking about
   `T: Trait` instead
 - the root trait is not `Unsize`, as to avoid talking about it in
   `tests/ui/coercion/coerce-issue-49593-box-never.rs`.

```
error[E0277]: the trait bound `&char: Pattern<'_>` is not satisfied
  --> $DIR/root-obligation.rs:6:38
   |
LL |         .filter(|c| "aeiou".contains(c))
   |                             -------- ^ the trait `Fn<(char,)>` is not implemented for `&char`, which is required by `&char: Pattern<'_>`
   |                             |
   |                             required by a bound introduced by this call
   |
   = note: required for `&char` to implement `FnOnce<(char,)>`
   = note: required for `&char` to implement `Pattern<'_>`
note: required by a bound in `core::str::<impl str>::contains`
  --> $SRC_DIR/core/src/str/mod.rs:LL:COL
help: consider dereferencing here
   |
LL |         .filter(|c| "aeiou".contains(*c))
   |                                      +
```

Fix rust-lang#79359, fix rust-lang#119983, fix rust-lang#118779, cc rust-lang#118415 (the suggestion needs
to change).
… methods on non-`Iterator`

```
error[E0599]: no method named `map` found for struct `Vec<bool>` in the current scope
  --> $DIR/vec-on-unimplemented.rs:3:23
   |
LL |     vec![true, false].map(|v| !v).collect::<Vec<_>>();
   |                       ^^^ `Vec<bool>` is not an iterator
   |
help: call `.into_iter()` first
   |
LL |     vec![true, false].into_iter().map(|v| !v).collect::<Vec<_>>();
   |                       ++++++++++++
```

We used to provide some help through `rustc_on_unimplemented` on non-`impl Trait` and non-type-params, but this lets us get rid of some otherwise unnecessary conditions in the annotation on `Iterator`.
As this can cause panics on array accesses later.
Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com>
…nieu

Vec::try_with_capacity

Related to rust-lang#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)`).
…c-into-inner, 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.
…y, r=cuviper

Add vector time complexity

Added time complexity for `Vec` methods `push`, `push_within_capacity`, `pop`, and `insert`.

<details>

<summary> Reference images </summary>

![`Vec::push` documentation](https://github.com/rust-lang/rust/assets/78604367/dc966bbd-e92e-45a6-af82-35afabfa79a9)

![`Vec::push_within_capacity` documentation](https://github.com/rust-lang/rust/assets/78604367/9aadaf48-46ed-4fad-bdd5-74b98a61f4bb)

![`Vec::pop` documentation](https://github.com/rust-lang/rust/assets/78604367/88ec0389-a346-4ea5-a3b7-17caf514dd8b)

![`Vec::insert` documentation](https://github.com/rust-lang/rust/assets/78604367/960c15c3-ef8e-4aa7-badc-35ce80f6f221)

</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.
…viper

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]`.
…r=oli-obk

Use root obligation on E0277 for some cases

When encountering trait bound errors that satisfy some heuristics that tell us that the relevant trait for the user comes from the root obligation and not the current obligation, we use the root predicate for the main message.

This allows to talk about "X doesn't implement Pattern<'_>" over the most specific case that just happened to fail, like  "char doesn't implement Fn(&mut char)" in
`tests/ui/traits/suggest-dereferences/root-obligation.rs`

The heuristics are:

 - the type of the leaf predicate is (roughly) the same as the type from the root predicate, as a proxy for "we care about the root"
 - the leaf trait and the root trait are different, so as to avoid talking about `&mut T: Trait` and instead remain talking about `T: Trait` instead
 - the root trait is not `Unsize`, as to avoid talking about it in `tests/ui/coercion/coerce-issue-49593-box-never.rs`.

```
error[E0277]: the trait bound `&char: Pattern<'_>` is not satisfied
  --> $DIR/root-obligation.rs:6:38
   |
LL |         .filter(|c| "aeiou".contains(c))
   |                             -------- ^ the trait `Fn<(char,)>` is not implemented for `&char`, which is required by `&char: Pattern<'_>`
   |                             |
   |                             required by a bound introduced by this call
   |
   = note: required for `&char` to implement `FnOnce<(char,)>`
   = note: required for `&char` to implement `Pattern<'_>`
note: required by a bound in `core::str::<impl str>::contains`
  --> $SRC_DIR/core/src/str/mod.rs:LL:COL
help: consider dereferencing here
   |
LL |         .filter(|c| "aeiou".contains(*c))
   |                                      +
```

Fix rust-lang#79359, fix rust-lang#119983, fix rust-lang#118779, cc rust-lang#118415 (the suggestion needs to change), cc rust-lang#121398 (doesn't fix the underlying issue).
…x, r=compiler-errors

Use the correct logic for nested impl trait in assoc types

Previously we accidentally continued with the TAIT visitor, which allowed more than we wanted to.

r? ``@compiler-errors``
Don't panic when waiting on poisoned queries

This fixes a bug introduced in rust-lang#119086.
… r=compiler-errors

pattern analysis: abort on arity mismatch

This is one more PR replacing panics by `Err()` aborts. I recently audited all the `unwrap()` calls, but I had forgotten about array accesses. (Again [discovered by rust-analyzer](rust-lang/rust-analyzer#16746)).

r? ``@compiler-errors``
…compiler-errors

Avoid using unnecessary queries when printing the query stack in panics

This should fix rust-lang#121974. Alternative to rust-lang#121981.
…-errors

interpret/cast: make more matches on FloatTy properly exhaustive

Actually implementing these is pretty trivial (at least once all the scalar methods are added, which happens in rust-lang#121926), but I'm staying consistent with the other f16/f128 PRs. Also adding adding all the tests to Miri would be quite a lot of work.

There's probably some way to reduce the code duplication here with more use of generics... but that's a future refactor.^^

r? ``@tgross35``
@rustbot rustbot added A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Mar 5, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=10

@bors
Copy link
Contributor

bors commented Mar 5, 2024

📌 Commit 99a7802 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 5, 2024
@tgross35
Copy link
Contributor

tgross35 commented Mar 5, 2024

@matthiaskrgr #121262 could use a squash if you wanna enforce that

@matthiaskrgr matthiaskrgr deleted the rollup-twvjuph branch March 16, 2024 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet