Sometimes when writing generic code you want to abstract over
owning/pointer type so that calling code isn't restricted by one
concrete owning/pointer type. This commit makes possible such code:
```rust
fn i_will_work_with_arc<T: Into<Arc<MyTy>>>(t: T) {
let the_arc = t.into();
// Do something
}
i_will_work_with_arc(MyTy::new());
i_will_work_with_arc(Box::new(MyTy::new()));
let arc_that_i_already_have = Arc::new(MyTy::new());
i_will_work_with_arc(arc_that_i_already_have);
```
Please note that this patch doesn't work with DSTs.
Also to mention, I made those impls stable, and I don't know whether they should be actually stable from the beginning. Please tell me if this should be feature-gated.
Fixes#29853Fixes#29852
While these points are true, we're not going for 100% accuracy here,
this is introductory material. Changing these things would be more
confusing, but it is important to note that we're presenting an
abstraction here.
insert() returns bool, but it was wrongly stated that if the set had the
key already present, that key would be returned (this was probably
copied from the HashMap docs). Also remove a reference to the
module-level documentation, which doesn't make sense as it doesn't give
any more context.
r? @steveklabnik
This should get `--libdir` working as well as it was a couple of weeks ago. (That is, it still rewrites paths incorrectly but it no longer fails during `make install`.)
Fixesgentoo/gentoo-rust#28 and gentoo/gentoo-rust#29.
insert() returns bool, but it was wrongly stated that if the set had the
key already present, that key would be returned (this was probably
copied from the HashMap docs). Also remove a reference to the
module-level documentation, which doesn't make sense as it doesn't give
any more context.
This is to handle the case where CFG_LIBDIR is not a direct child of
CFG_PREFIX (in other words, where CFG_LIBDIR_RELATIVE has more than
one component).
f357d55 caused a regression by retrieving item names from metadata, while previously using the last element of its absolute path (which in the case of a root module is the prefixed crate name since the stored path in metadata is empty)
fixes#28927
Another rustfmt PR.
I ran rustfmt, then split the changes in multiple commits. First commit are the non-problematic changed. The others are all the little weirdness that caught my attention and could be discussed.
These really aren't documented well at all. The fact that doc comments end on a `*/` is really weird. I'm not sure if this is a mistake or not though.
None of the block comments are even mentioned in the [book nightly](http://doc.rust-lang.org/nightly/book/comments.html). Probably should be fixed.
