diff options
| author | Anthony Ramine <n.oxyde@gmail.com> | 2018-03-31 23:19:02 +0200 |
|---|---|---|
| committer | Anthony Ramine <n.oxyde@gmail.com> | 2018-04-01 11:56:23 +0200 |
| commit | 360f2f036d14889f4de37a8b4b6aad0d09772aad (patch) | |
| tree | 1635a617fe742c3d3c08ed120acb15034a807a99 /src/test/incremental/thinlto | |
| parent | 8dd24c8ed4ac3e48068408fa21d491d7ffe45295 (diff) | |
| download | rust-360f2f036d14889f4de37a8b4b6aad0d09772aad.tar.gz rust-360f2f036d14889f4de37a8b4b6aad0d09772aad.zip | |
Inline most of the code paths for conversions with boxed slices
This helps with the specific problem described in #49541, obviously without
making any large change to how inlining works in the general case.
Everything involved in the conversions is made `#[inline]`, except for the
`<Vec<T>>::into_boxed_slice` entry point which is made `#[inline(always)]`
after checking that duplicating the function mentioned in the issue prevented
its inlining if I only annotate it with `#[inline]`.
For the record, that function was:
```rust
pub fn foo() -> Box<[u8]> {
vec![0].into_boxed_slice()
}
```
To help the inliner's job, we also hoist a `self.capacity() != self.len` check
in `<Vec<T>>::shrink_to_fit` and mark it as `#[inline]` too.
Diffstat (limited to 'src/test/incremental/thinlto')
0 files changed, 0 insertions, 0 deletions
