add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate
Implement <https://github.com/rust-lang/rfcs/pull/2714>
### tl;dr
This PR adds a `extend_from_within` method to `Vec` which allows copying elements from a range to the end:
```rust
#![feature(vec_extend_from_within)]
let mut vec = vec![0, 1, 2, 3, 4];
vec.extend_from_within(2..);
assert_eq!(vec, [0, 1, 2, 3, 4, 2, 3, 4]);
vec.extend_from_within(..2);
assert_eq!(vec, [0, 1, 2, 3, 4, 2, 3, 4, 0, 1]);
vec.extend_from_within(4..8);
assert_eq!(vec, [0, 1, 2, 3, 4, 2, 3, 4, 0, 1, 4, 2, 3, 4]);
```
### Implementation notes
Originally I've copied `@Shnatsel's` [implementation](690742a0de/src/lib.rs (L74)) with some minor changes to support other ranges:
```rust
pub fn append_from_within<R>(&mut self, src: R)
where
T: Copy,
R: RangeBounds<usize>,
{
let len = self.len();
let Range { start, end } = src.assert_len(len);;
let count = end - start;
self.reserve(count);
unsafe {
// This is safe because `reserve()` above succeeded,
// so `self.len() + count` did not overflow usize
ptr::copy_nonoverlapping(
self.get_unchecked(src.start),
self.as_mut_ptr().add(len),
count,
);
self.set_len(len + count);
}
}
```
But then I've realized that this duplicates most of the code from (private) `Vec::append_elements`, so I've used it instead.
Then I've applied `@KodrAus` suggestions from https://github.com/rust-lang/rust/pull/79015#issuecomment-727200852.
Update armhf-gnu to Ubuntu 20.04
This requires updating the used Linux kernel to avoid an assembler
error, the used busybox version to avoid a linker error, the used
rootfs to match the host version and the qemu flags to work with
the newer version.
r? `@Mark-Simulacrum`
Update cargo
5 commits in c3abcfe8a75901c7c701557a728941e8fb19399e..e099df243bb2495b9b197f79c19f124032b1e778
2021-01-25 16:16:43 +0000 to 2021-02-01 16:24:34 +0000
- Impl warn for locked install without Cargo.lock (rust-lang/cargo#9108)
- Document -Z extra-link-arg. (rust-lang/cargo#9121)
- Flip 'foo' and 'bar' to be consistent (rust-lang/cargo#9120)
- Don't try to parse MSRV if feature is not enabled (rust-lang/cargo#9115)
- simplify char range check (rust-lang/cargo#9110)
Fix primitive search in parameters and returned values
Part of #60485.
Fixes#74780.
Replacing #74879.
cc `@camelid` `@jyn514` `@CraftSpider`
r? `@ollie27`
- This allows us add fake information after handling migrations if
needed.
- Capture analysis also priortizes what we see earlier, which means
fake information should go in last.
The different impls are all guarded by cfg-flags, and the revisions could be
used to cover the full power-set of combinations.
(I only included 20 of the possible 32 cases here; the null-set is not
interesting, and the remaining 11 all yielded ambiguous method resolution errors
which did not mix well with this testing strategy; I'm not trying to check UI
for the resolution diagnostics; I'm trying to create checkpoint of current
resolution semantics when compilation succeeds.)
Add visitors for checking #[inline]
Add visitors for checking #[inline] with struct field
Fix test for #[inline]
Add visitors for checking #[inline] with #[macro_export] macro
Add visitors for checking #[inline] without #[macro_export] macro
Add use alias with Visitor
Fix lint error
Reduce unnecessary variable
Co-authored-by: LingMan <LingMan@users.noreply.github.com>
Change error to warning
Add warning for checking field, arm with #[allow_internal_unstable]
Add name resolver
Formatting
Formatting
Fix error fixture
Add checking field, arm, macro def
Sync rustc_codegen_cranelift
The highlight of this sync are abi compatibility with cg_llvm allowing mixing of cg_clif and cg_llvm compiled crates and switching to the x64 cranelift backend based on the new backend framework.
r? ``@ghost``
``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Fix calling convention for CRT startup
My PR #81478 used the wrong calling convention for a set of
functions that are called by the CRT. These functions need to use
`extern "C"`.
This would only affect x86, which is the only target (that I know of)
that has multiple calling conventions.
```@bors``` r? ```@m-ou-se```
Avoid building LLVM just for llvm-dwp
When the LLVM backend is disabled, the llvm-project submodule is not checked out by default. This breaks the bootstrap test for cg_clif. As cg_clif doesn't support split debuginfo anyway llvm-dwp is not necessary. Other backends would likely not want to build LLVM just for llvm-dwp either.
Fixes https://github.com/bjorn3/rustc_codegen_cranelift/issues/1119
Indicate both start and end of pass RSS in time-passes output
Previously, only the end of pass RSS was indicated. This could easily
lead one to believe that the change in RSS from one pass to the next was
attributable to the second pass, when in fact it occurred between the
end of the first pass and the start of the second.
Also, improve alignment of columns.
Sample of output:
```
time: 0.739; rss: 607MB -> 637MB item_types_checking
time: 8.429; rss: 637MB -> 775MB item_bodies_checking
time: 11.063; rss: 470MB -> 775MB type_check_crate
time: 0.232; rss: 775MB -> 777MB match_checking
time: 0.139; rss: 777MB -> 779MB liveness_and_intrinsic_checking
time: 0.372; rss: 775MB -> 779MB misc_checking_2
time: 8.188; rss: 779MB -> 1019MB MIR_borrow_checking
time: 0.062; rss: 1019MB -> 1021MB MIR_effect_checking
```
Add error message for private fn
Attempts to add a more detailed error when a `const_evaluatable` fn from another scope is used inside of a scope which cannot access it.
r? ````@lcnr````
