With the latter is provided by the `From` conversion trait, the former is now completely redundant. Their code is identical. Let’s deprecate now and plan to remove in the next cycle. (It’s `#[unstable]`.)
r? @alexcrichton
CC @nagisa
I had to use `impl<'a, V: Copy> Extend<(usize, &'a V)> for VecMap<V>` instead of `impl<'a, V: Copy> Extend<(&'a usize, &'a V)> for VecMap<V>` as that's what is needed for doing
```rust
let mut a = VecMap::new();
let b = VecMap::new();
b.insert(1, "foo");
a.extend(&b)
```
I can squash the commits after review.
r? @Gankro
Closes#19826
r? @nikomatsakis
There is still some work to do until parallel codegen is perfect - we don't pass make check due to missing the symbol for registering a macro. But we do bootstrap with codegen_units=4 and pass make check without codegen_units, so I think it should land.
For the curious, make rustc-stage2 -j8:
```
codegen_units=1:
real 9m18.074s
user 11m59.858s
sys 0m13.281s
codegen_units=4:
real 6m3.672s
user 13m5.474s
sys 0m12.146s
```
Which is a 33% speedup :-)
Based on the patch from Luca Bruno.
Instead of creating an empty C function in the rt, this version creates an shim
noop function using llvm. This function is declared as internal, and the
unsupported assume intrinsic and the shim gets completly removed by the
optimizer.
This commit introduce a third parameter for compatible_ifn!, as new
intrinsics are being added in recent LLVM releases and there is no
need to hardcode a specific case.
Signed-off-by: Luca Bruno <lucab@debian.org>
This makes the maximum edit distance of typo suggestions a function of the typo'd name's length. FWIW, clang uses this same hueristic, and I've found their suggestions to be better than rustc's. Without something like this, you end up with suggestions that aren't related at all when there are short variable names.
See also https://github.com/rust-lang/rust/issues/20028#issuecomment-109767159
For a user following the path of reading Chapter 5: Syntax & Symantics
prior to Chapter 4: Learn Rust, this will be the first time they have
encountered executable tests inside documentation comments.
The test will fail because the `add_one` function is not defined in
the context of the doctest. This might not be the optimal place to
introduce and explain the `/// #` notation but I think it is important
that this snippet pass as a test when `rustdoc --test` is run against
it if it is going to be shown.
The sensible default used here for the version number in the
auto-generated Cargo.toml is 0.1.0, not 0.0.1 (at least as of cargo
0.2.0-nightly efb482d).
The recent bug that was found in LinkedList reminded me of some general cleanup
that's been waiting for some time.
- Use a loop from the front in Drop, it works just as well and without an unsafe block
- Change Rawlink methods to use `unsafe` in an idiomatic way. This does mean that
we need an unsafe block for each dereference of a raw link. Even then, the extent
of unsafe-critical code is even larger of course, since safety depends on the whole
data structure's integrity. This is a general problem we are aware of.
- Some cleanup just to try to decrease the amount of Rawlink handling.
