Commit Graph

1618 Commits

Author SHA1 Message Date
bors
e209e85e39 Auto merge of #95183 - ibraheemdev:arc-count-acquire, r=Amanieu
Weaken needlessly restrictive orderings on `Arc::*_count`

There is no apparent reason for these to be `SeqCst`. For reference, [the Boost C++ implementation relies on acquire semantics](f2cc84a23c/include/boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp (L137-L140)).
2022-05-06 14:53:24 +00:00
bors
8c4fc9d9a4 Auto merge of #94598 - scottmcm:prefix-free-hasher-methods, r=Amanieu
Add a dedicated length-prefixing method to `Hasher`

This accomplishes two main goals:
- Make it clear who is responsible for prefix-freedom, including how they should do it
- Make it feasible for a `Hasher` that *doesn't* care about Hash-DoS resistance to get better performance by not hashing lengths

This does not change rustc-hash, since that's in an external crate, but that could potentially use it in future.

Fixes #94026

r? rust-lang/libs

---

The core of this change is the following two new methods on `Hasher`:

```rust
pub trait Hasher {
    /// Writes a length prefix into this hasher, as part of being prefix-free.
    ///
    /// If you're implementing [`Hash`] for a custom collection, call this before
    /// writing its contents to this `Hasher`.  That way
    /// `(collection![1, 2, 3], collection![4, 5])` and
    /// `(collection![1, 2], collection![3, 4, 5])` will provide different
    /// sequences of values to the `Hasher`
    ///
    /// The `impl<T> Hash for [T]` includes a call to this method, so if you're
    /// hashing a slice (or array or vector) via its `Hash::hash` method,
    /// you should **not** call this yourself.
    ///
    /// This method is only for providing domain separation.  If you want to
    /// hash a `usize` that represents part of the *data*, then it's important
    /// that you pass it to [`Hasher::write_usize`] instead of to this method.
    ///
    /// # Examples
    ///
    /// ```
    /// #![feature(hasher_prefixfree_extras)]
    /// # // Stubs to make the `impl` below pass the compiler
    /// # struct MyCollection<T>(Option<T>);
    /// # impl<T> MyCollection<T> {
    /// #     fn len(&self) -> usize { todo!() }
    /// # }
    /// # impl<'a, T> IntoIterator for &'a MyCollection<T> {
    /// #     type Item = T;
    /// #     type IntoIter = std::iter::Empty<T>;
    /// #     fn into_iter(self) -> Self::IntoIter { todo!() }
    /// # }
    ///
    /// use std:#️⃣:{Hash, Hasher};
    /// impl<T: Hash> Hash for MyCollection<T> {
    ///     fn hash<H: Hasher>(&self, state: &mut H) {
    ///         state.write_length_prefix(self.len());
    ///         for elt in self {
    ///             elt.hash(state);
    ///         }
    ///     }
    /// }
    /// ```
    ///
    /// # Note to Implementers
    ///
    /// If you've decided that your `Hasher` is willing to be susceptible to
    /// Hash-DoS attacks, then you might consider skipping hashing some or all
    /// of the `len` provided in the name of increased performance.
    #[inline]
    #[unstable(feature = "hasher_prefixfree_extras", issue = "88888888")]
    fn write_length_prefix(&mut self, len: usize) {
        self.write_usize(len);
    }

    /// Writes a single `str` into this hasher.
    ///
    /// If you're implementing [`Hash`], you generally do not need to call this,
    /// as the `impl Hash for str` does, so you can just use that.
    ///
    /// This includes the domain separator for prefix-freedom, so you should
    /// **not** call `Self::write_length_prefix` before calling this.
    ///
    /// # Note to Implementers
    ///
    /// The default implementation of this method includes a call to
    /// [`Self::write_length_prefix`], so if your implementation of `Hasher`
    /// doesn't care about prefix-freedom and you've thus overridden
    /// that method to do nothing, there's no need to override this one.
    ///
    /// This method is available to be overridden separately from the others
    /// as `str` being UTF-8 means that it never contains `0xFF` bytes, which
    /// can be used to provide prefix-freedom cheaper than hashing a length.
    ///
    /// For example, if your `Hasher` works byte-by-byte (perhaps by accumulating
    /// them into a buffer), then you can hash the bytes of the `str` followed
    /// by a single `0xFF` byte.
    ///
    /// If your `Hasher` works in chunks, you can also do this by being careful
    /// about how you pad partial chunks.  If the chunks are padded with `0x00`
    /// bytes then just hashing an extra `0xFF` byte doesn't necessarily
    /// provide prefix-freedom, as `"ab"` and `"ab\u{0}"` would likely hash
    /// the same sequence of chunks.  But if you pad with `0xFF` bytes instead,
    /// ensuring at least one padding byte, then it can often provide
    /// prefix-freedom cheaper than hashing the length would.
    #[inline]
    #[unstable(feature = "hasher_prefixfree_extras", issue = "88888888")]
    fn write_str(&mut self, s: &str) {
        self.write_length_prefix(s.len());
        self.write(s.as_bytes());
    }
}
```

With updates to the `Hash` implementations for slices and containers to call `write_length_prefix` instead of `write_usize`.

`write_str` defaults to using `write_length_prefix` since, as was pointed out in the issue, the `write_u8(0xFF)` approach is insufficient for hashers that work in chunks, as those would hash `"a\u{0}"` and `"a"` to the same thing.  But since `SipHash` works byte-wise (there's an internal buffer to accumulate bytes until a full chunk is available) it overrides `write_str` to continue to use the add-non-UTF-8-byte approach.

---

Compatibility:

Because the default implementation of `write_length_prefix` calls `write_usize`, the changed hash implementation for slices will do the same thing the old one did on existing `Hasher`s.
2022-05-06 09:43:57 +00:00
Scott McMurray
98054377ee Add a dedicated length-prefixing method to Hasher
This accomplishes two main goals:
- Make it clear who is responsible for prefix-freedom, including how they should do it
- Make it feasible for a `Hasher` that *doesn't* care about Hash-DoS resistance to get better performance by not hashing lengths

This does not change rustc-hash, since that's in an external crate, but that could potentially use it in future.
2022-05-06 00:03:38 -07:00
Matthias Krüger
3f07303efe
Rollup merge of #95843 - GuillaumeGomez:improve-new-cyclic-doc, r=m-ou-se
Improve Rc::new_cyclic and Arc::new_cyclic documentation

Fixes https://github.com/rust-lang/rust/issues/95672.

cc `@CAD97` (since I used your explanations)
2022-05-05 15:43:02 +02:00
bors
12d3f107c1 Auto merge of #96626 - thomcc:rand-bump, r=m-ou-se
Avoid using `rand::thread_rng` in the stdlib benchmarks.

This is kind of an anti-pattern because it introduces extra nondeterminism for no real reason. In thread_rng's case this comes both from the random seed and also from the reseeding operations it does, which occasionally does syscalls (which adds additional nondeterminism). The impact of this would be pretty small in most cases, but it's a good practice to avoid (particularly because avoiding it was not hard).

Anyway, several of our benchmarks already did the right thing here anyway, so the change was pretty easy and mostly just applying it more universally. That said, the stdlib benchmarks aren't particularly stable (nor is our benchmark framework particularly great), so arguably this doesn't matter that much in practice.

~~Anyway, this also bumps the `rand` dev-dependency to 0.8, since it had fallen somewhat out of date.~~ Nevermind, too much of a headache.
2022-05-05 05:08:44 +00:00
Guillaume Gomez
67d1e7b8ff Improve Rc::new_cyclic and Arc::new_cyclic documentation 2022-05-04 15:20:02 +02:00
bors
6b6c1ffacc Auto merge of #96596 - scottmcm:limited-calloc, r=Mark-Simulacrum
Tweak the vec-calloc runtime check to only apply to shortish-arrays

r? `@Mark-Simulacrum`

`@nbdd0121` pointed out in https://github.com/rust-lang/rust/pull/95362#issuecomment-1114085395 that LLVM currently doesn't constant-fold the `IsZero` check for long arrays, so that seems like a reasonable justification for limiting it.

It appears that it's based on length, not byte size, (https://godbolt.org/z/4s48Y81dP), so that's what I used in the PR.  Maybe it's a ["the number of inlining shall be three"](https://youtu.be/s4wnuiCwTGU?t=320) sort of situation.

Certainly there's more that could be done here -- that generated code that checks long arrays byte-by-byte is highly suboptimal, for example -- but this is an easy, low-risk tweak.
2022-05-02 09:05:22 +00:00
Thom Chiovoloni
0812759840
Avoid use of rand::thread_rng in stdlib benchmarks 2022-05-02 00:08:21 -07:00
Scott McMurray
2830dbd64f Tweak the calloc optimization to only apply to shortish-arrays 2022-05-01 22:28:11 -07:00
Yuki Okushi
ab1ae48cce
Rollup merge of #96568 - EliasHolzmann:fmt_doc_fixes, r=joshtriplett
std::fmt: Various fixes and improvements to documentation

This PR contains the following changes:

- **Added argument index comments to examples for specifying precision**

  The examples for specifying the precision have comments explaining which
  argument the specifier is referring to. However, for implicit positional
  arguments, the examples simply refer to "next arg". To simplify following the
  comments, "next arg" was supplemented with the actual resulting argument index.

- **Fixed documentation for specifying precision via `.*`**

  The documentation stated that in case of the syntax `{<arg>:<spec>.*}`, "the
  `<arg>` part refers to the value to print, and the precision must come in the
  input preceding `<arg>`". This is not correct: the <arg> part does indeed refer
  to the value to print, but the precision does not come in the input preciding
  arg, but in the next implicit input (as if specified with {}).

  Fixes #96413.

- **Fix the grammar documentation**

  According to the grammar documented, the format specifier `{: }` should not be
  legal because of the whitespace it contains. However, in reality, this is
  perfectly fine because the actual implementation allows spaces before the
  closing brace. Fixes #71088.

  Also, the exact meaning of most of the terminal symbols was not specified, for
  example the meaning of `identifier`.

- **Removed reference to Formatter::buf and other private fields**

  Formatter::buf is not a public field and therefore isn't very helpful in user-
  facing documentation. Also, the other public fields of Formatter were removed
  during stabilization of std::fmt (4af3494bb0) and can only be accessed via
  getters.

- **Improved list of formatting macros**

  Two improvements:
  1. write! can not only receive a `io::Write`, but also a `fmt::Write` as first argument.
  2. The description texts now contain links to the actual macros for easier
     navigation.
2022-05-02 10:41:58 +09:00
Yuki Okushi
1785f1549c
Rollup merge of #96222 - jmaargh:john-mark/clarify-from-raw-parts-docs, r=JohnTitor
Clarify docs for `from_raw_parts` on `Vec` and `String`

Closes #95427

Original safety explanation for `from_raw_parts` was unclear on safety for consuming a C string. This clarifies when doing so is safe.
2022-05-02 10:41:55 +09:00
Yuki Okushi
ddfc65dae0
Rollup merge of #94126 - ssomers:alloc_prep_1, r=Mark-Simulacrum
Classify BinaryHeap & LinkedList unit tests as such

All but one of these so-called integration test case are unit tests, just like btree's were (#75531). In addition, reunite the unit tests of linked_list that were split off during #23104 because they needed to remain unit tests (they were later moved to the separate file they are in during #63207). The two sets could remain separate files, but I opted to merge them back together, more or less in the order they used to be, apart from one duplicate name `test_split_off` and one duplicate tiny function `list_from`.
2022-05-02 10:41:54 +09:00
Elias Holzmann
f3b86c37eb std::fmt: Improved list of formatting macros
Two improvements:
1. write! can not only receive a `io::Write`, but also a `fmt::Write` as first argument.
2. The description texts now contain links to the actual macros for easier
   navigation.
2022-05-01 15:27:41 +02:00
Elias Holzmann
c70f3ab5e5 std::fmt: Removed reference to Formatter::buf and other private fields
Formatter::buf is not a public field and therefore isn't very helpful in user-
facing documentation. Also, the other public fields of Formatter were made
private during stabilization of std::fmt (4af3494bb0) and can now only be read
via accessor methods.
2022-05-01 15:27:41 +02:00
Elias Holzmann
79d9afda13 std::fmt: Fix the grammar documentation
According to the grammar documented, the format specifier `{: }` should not be
legal because of the whitespace it contains. However, in reality, this is
perfectly fine because the actual implementation allows spaces before the
closing brace. Fixes #71088.

Also, the exact meaning of most of the terminal symbols was not specified, for
example the meaning of `identifier`.
2022-05-01 15:27:41 +02:00
Elias Holzmann
afd80a21b0 std::fmt: Added argument index comments to examples for specifying precision
The examples for specifying the precision have comments explaining which
argument the specifier is referring to. However, for implicit positional
arguments, the examples simply talk about "next arg". To make it easier for
readers to follow the comments, "next arg" was supplemented with the actual
resulting argument index.
2022-05-01 15:27:40 +02:00
Elias Holzmann
1288883932 std::fmt: Fixed documentation for specifying precision via .*
The documentation stated that in case of the syntax `{<arg>:<spec>.*}`, "the
`<arg>` part refers to the value to print, and the precision must come in the
input preceding `<arg>`". This is not correct: the <arg> part does indeed refer
to the value to print, but the precision does not come in the input preciding
arg, but in the next implicit input (as if specified with {}).

Fixes #96413.
2022-05-01 15:26:15 +02:00
bors
f75d884046 Auto merge of #96078 - udoprog:refcounted-str-to-u8, r=dtolnay
Implement str to [u8] conversion for refcounted containers

This seems motivated to complete the APIs for shared containers since we already have similar allocation-free conversions for strings like `From<Box<[u8]>> for Box<str>`.

Insta-stable since it's a new trait impl?
2022-05-01 06:41:59 +00:00
David Tolnay
100006bec9
Bump shared_from_str to Rust 1.62.0 2022-04-30 23:40:35 -07:00
bors
bf611439e3 Auto merge of #95362 - scottmcm:calloc-arrays, r=Mark-Simulacrum
Support arrays of zeros in Vec's __rust_alloc_zeroed optimization

I happened to notice in https://users.rust-lang.org/t/any-advantage-of-box-u64-16-16-16-over-vec-u64/73500/3?u=scottmcm that the calloc optimization wasn't applying to vectors-of-arrays, so here's the easy fix for that.
2022-05-01 00:50:46 +00:00
bors
f1d8a7d662 Auto merge of #96489 - shepmaster:revert-vec-from-array-ref, r=yaahc
Revert "impl From<&[T; N]> and From<&mut [T; N]> for Vec<T>"

This reverts commit 5dd702763a.
2022-04-29 14:39:14 +00:00
Dylan DPC
cd5dc49379
Rollup merge of #96492 - joshtriplett:revert-std-ffi-re-export, r=yaahc
Revert "Re-export core::ffi types from std::ffi"

This reverts commit 9aed829fe6.

Fixes https://github.com/rust-lang/rust/issues/96435 , a regression
in crates doing `use std::ffi::*;` and `use std::os::raw::*;`.

We can re-add this re-export once the `core::ffi` types
are stable, and thus the `std::os::raw` types can become re-exports as
well, which will avoid the conflict. (Type aliases to the same type
still conflict, but re-exports of the same type don't.)
2022-04-29 11:23:14 +02:00
Paolo Barbolini
c126f7fc8b Add VecDeque::extend from vec::IntoIter and slice::Iter specializations 2022-04-28 06:13:54 +02:00
Josh Triplett
42d96bb2f6 Remove use of reverted std::ffi::c_char 2022-04-27 14:01:04 -07:00
Jake Goulding
762bb1f506 Revert "impl From<&[T; N]> and From<&mut [T; N]> for Vec<T>"
This reverts commit 5dd702763a.
2022-04-27 15:56:29 -04:00
Paolo Barbolini
84b8898d63 Add VecDeque::extend benchmark 2022-04-27 21:10:20 +02:00
Guillaume Gomez
eaf8beb3f3
Rollup merge of #94022 - jongiddy:cow-into-owned-docs, r=Dylan-DPC
Clarify that `Cow::into_owned` returns owned data

Two sections of the `Cow::into_owned` docs imply that `into_owned` returns a `Cow`. Clarify that it returns the underlying owned object, either cloned or extracted from the `Cow`.
2022-04-26 13:22:26 +02:00
Dylan DPC
51b86848ff
Rollup merge of #90312 - r00ster91:search, r=Dylan-DPC
Fix some confusing wording and improve slice-search-related docs

This adds more links between `contains` and `binary_search` because I do think they have some relevant connections. If your (big) slice happens to be sorted and you know it, surely you should be using `[3; 100].binary_search(&5).is_ok()` over `[3; 100].contains(&5)`?
This also fixes the confusing "searches this sorted X" wording which just sounds really weird because it doesn't know whether it's actually sorted. It should be but it may not be. The new wording should make it clearer that you will probably want to sort it and in the same sentence it also mentions the related function `contains`.
Similarly, this mentions `binary_search` on `contains`' docs.
This also fixes some other minor stuff and inconsistencies.
2022-04-26 01:21:20 +02:00
Matthias Krüger
b7e67a6ad9
Rollup merge of #96107 - Gumichocopengin8:test/vec-deque, r=Mark-Simulacrum
[test] Add test cases for untested functions for VecDeque

Added test cases of the following functions
- get
- get_mut
- swap
- reserve_exact
- try_reserve_exact
- try_reserve
- contains
- rotate_left
- rotate_right
- binary_search
- binary_search_by
- binary_search_by_key
2022-04-25 00:11:00 +02:00
Keita Nonaka
a40cd2aa8b test: add test cases for VecDeque 2022-04-24 11:43:07 -07:00
jmaargh
4dda047de3 Clarify docs for from_raw_parts
Original safety explanation for from_raw_parts was
unclear on safety for consuming a C string. This
clarifies when doing so is safe.
2022-04-19 21:12:55 +01:00
Dylan DPC
35188440b5
Rollup merge of #96089 - ojeda:no-vec-no_global_oom_handling, r=Mark-Simulacrum
`alloc`: make `vec!` unavailable under `no_global_oom_handling`

`alloc`: make `vec!` unavailable under `no_global_oom_handling`

The `vec!` macro has 3 rules, but two are not usable under
`no_global_oom_handling` builds of the standard library
(even with a zero size):

```rust
let _ = vec![42];    // Error: requires `exchange_malloc` lang_item.
let _ = vec![42; 0]; // Error: cannot find function `from_elem`.
```

Thus those two rules should not be available to begin with.

The remaining one, with an empty matcher, is just a shorthand for
`new()` and may not make as much sense to have alone, since the
idea behind `vec!` is to enable `Vec`s to be defined with the same
syntax as array expressions. Furthermore, the documentation can be
confusing since it shows the other rules.

Thus perhaps it is better and simpler to disable `vec!` entirely
under `no_global_oom_handling` environments, and let users call
`new()` instead:

```rust
let _: Vec<i32> = vec![];
let _: Vec<i32> = Vec::new();
```

Notwithstanding this, a `try_vec!` macro would be useful, such as
the one introduced in https://github.com/rust-lang/rust/pull/95051.

If the shorthand for `new()` is deemed worth keeping on its own,
then it may be interesting to have a separate `vec!` macro with
a single rule and different, simpler documentation.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-04-19 14:43:19 +02:00
bors
43a71dc732 Auto merge of #96002 - nnethercote:speed-up-Vec-clear-2, r=m-ou-se
Speed up Vec::clear().

Currently it just calls `truncate(0)`. `truncate()` is (a) not marked as
`#[inline]`, and (b) more general than needed for `clear()`.

This commit changes `clear()` to do the work itself. This modest change
was first proposed in rust-lang#74172, where the reviewer rejected it because
there was insufficient evidence that `Vec::clear()`'s performance
mattered enough to justify the change. Recent changes within rustc have
made `Vec::clear()` hot within `macro_parser.rs`, so the change is now
clearly worthwhile.

Although it doesn't show wins on CI perf runs, this seems to be because they
use PGO. But not all platforms currently use PGO. Also, local builds don't use
PGO, and `truncate` sometimes shows up in an over-represented fashion in local
profiles. So local profiling will be made easier by this change.

Note that this will also benefit `String::clear()`, because it just
calls `Vec::clear()`.

Finally, the commit removes the `vec-clear.rs` codegen test. It was
added in #52908. From before then until now, `Vec::clear()` just called
`Vec::truncate()` with a zero length. The body of Vec::truncate() has
changed a lot since then. Now that `Vec::clear()` is doing actual work
itself, and not just calling `Vec::truncate()`, it's not surprising that
its generated code includes a load and an icmp. I think it's reasonable
to remove this test.

r? `@m-ou-se`
2022-04-17 03:08:45 +00:00
Dylan DPC
04ccba8728
Rollup merge of #96070 - Gumichocopengin8:test/btree-map, r=thomcc
[test] Add test cases for untested functions for BTreeMap

- add `pop_first()`, `pop_last()`, `get_key_value()` and `try_insert()` test cases
2022-04-16 07:12:48 +02:00
Miguel Ojeda
8cec88ba76 alloc: make vec! unavailable under no_global_oom_handling
The `vec!` macro has 3 rules, but two are not usable under
`no_global_oom_handling` builds of the standard library
(even with a zero size):

```rust
let _ = vec![42];    // Error: requires `exchange_malloc` lang_item.
let _ = vec![42; 0]; // Error: cannot find function `from_elem`.
```

Thus those two rules should not be available to begin with.

The remaining one, with an empty matcher, is just a shorthand for
`new()` and may not make as much sense to have alone, since the
idea behind `vec!` is to enable `Vec`s to be defined with the same
syntax as array expressions. Furthermore, the documentation can be
confusing since it shows the other rules.

Thus perhaps it is better and simpler to disable `vec!` entirely
under `no_global_oom_handling` environments, and let users call
`new()` instead:

```rust
let _: Vec<i32> = vec![];
let _: Vec<i32> = Vec::new();
```

Notwithstanding this, a `try_vec!` macro would be useful, such as
the one introduced in https://github.com/rust-lang/rust/pull/95051.

If the shorthand for `new()` is deemed worth keeping on its own,
then it may be interesting to have a separate `vec!` macro with
a single rule and different, simpler documentation.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-04-16 06:31:41 +02:00
bors
bb1a03c4fc Auto merge of #95224 - mjbshaw:patch-1, r=yaahc
Optimize RcInnerPtr::inc_strong()/inc_weak() instruction count

Inspired by this internals thread: https://internals.rust-lang.org/t/rc-optimization-on-64-bit-targets/16362

[The generated assembly is a bit smaller](https://rust.godbolt.org/z/TeTnf6144) and is a more efficient usage of the CPU's instruction cache. `unlikely` doesn't impact any of the small artificial tests I've done, but I've included it in case it might help more complex scenarios when this is inlined.
2022-04-15 23:15:51 +00:00
Dylan DPC
224afadb3b
Rollup merge of #96034 - Gumichocopengin8:test/btree-set, r=Dylan-DPC
[test] Add test cases of untested functions for BTreeSet

- add [`is_superset()`](https://doc.rust-lang.org/std/collections/struct.BTreeSet.html#method.is_superset) and [`remove()`](https://doc.rust-lang.org/std/collections/struct.BTreeSet.html#method.remove) test cases for BTreeSet since these functions has no test cases.
2022-04-15 20:50:49 +02:00
John-John Tedro
594be707c4 Implement str to [u8] conversion for refcounted containers 2022-04-15 15:38:37 +02:00
Keita Nonaka
3f46ba6028 chore: formatting 2022-04-15 01:30:05 -07:00
Keita Nonaka
3f2f4a35ed test: add try_insert() test cases for BTreeSet 2022-04-15 01:12:00 -07:00
Keita Nonaka
e1626020d3 test: add get_key_value() test cases for BTreeSet 2022-04-15 00:04:03 -07:00
Keita Nonaka
4117e8c2d3 test: add pop_first() pop_last() test cases for BTreeSet 2022-04-14 23:40:05 -07:00
Vadim Petrochenkov
afa2e6f2ff Fix targets not supporting target_has_atomic = "ptr" 2022-04-14 21:53:11 +03:00
Vadim Petrochenkov
7f3cc2fbbf library: Use type aliases to make CStr(ing) in libcore/liballoc unstable 2022-04-14 21:53:11 +03:00
Vadim Petrochenkov
5bee741a08 library: Move CStr to libcore, and CString to liballoc 2022-04-14 21:53:11 +03:00
Keita Nonaka
50c339e8f5 test: add remove() test cases for BTreeSet 2022-04-13 22:19:08 -07:00
Keita Nonaka
21d3f8444a test: add is_superset test cases for BTreeSet 2022-04-13 22:09:03 -07:00
Nicholas Nethercote
9c59d04d55 Speed up Vec::clear().
Currently it just calls `truncate(0)`. `truncate()` is (a) not marked as
`#[inline]`, and (b) more general than needed for `clear()`.

This commit changes `clear()` to do the work itself. This modest change
was first proposed in rust-lang#74172, where the reviewer rejected it because
there was insufficient evidence that `Vec::clear()`'s performance
mattered enough to justify the change. Recent changes within rustc have
made `Vec::clear()` hot within `macro_parser.rs`, so the change is now
clearly worthwhile.

Although it doesn't show wins on CI perf runs, this seems to be because they
use PGO. But not all platforms currently use PGO. Also, local builds don't use
PGO, and `truncate` sometimes shows up in an over-represented fashion in local
profiles. So local profiling will be made easier by this change.

Note that this will also benefit `String::clear()`, because it just
calls `Vec::clear()`.

Finally, the commit removes the `vec-clear.rs` codegen test. It was
added in #52908. From before then until now, `Vec::clear()` just called
`Vec::truncate()` with a zero length. The body of Vec::truncate() has
changed a lot since then. Now that `Vec::clear()` is doing actual work
itself, and not just calling `Vec::truncate()`, it's not surprising that
its generated code includes a load and an icmp. I think it's reasonable
to remove this test.
2022-04-13 15:39:35 +10:00
Josh Stone
a2902ebe57 impl const Default for Box<[T]> and Box<str> 2022-04-11 12:14:18 -07:00
Matthias Krüger
5b8e2ea520
Rollup merge of #95917 - RalfJung:thin-box-test, r=dtolnay
thin_box test: import from std, not alloc

Importing from `alloc` makes [Miri fail](https://github.com/rust-lang/miri-test-libstd/runs/5964922742?check_suite_focus=true), probably due to the hack that we used to resolve https://github.com/rust-lang/miri-test-libstd/issues/4. There might be better ways around this, but for now this is the easiest thing to do -- no other alloc integration test is importing from `alloc::`.
2022-04-11 12:06:58 +02:00