This is the same approach taken in #24270, except that this
should not be a breaking change because it only changes the output
of hash functions, which nobody should be relying on.
add regression test for try!
Our widespread internal use of `try` was like a regression test. Now that most of `try!`s have been converted to `?`, lets add a proper regression test.
cc @bstrie
Flatten rustc and rustc_trans module hierarchy slightly.
The following moves were made, in the name of sanity/simplicity:
* `rustc::middle::{cfg, infer, traits, ty}` to `rustc::{cfg, infer, traits, ty}`
* `rustc::middle::subst` to `rustc::ty::subst`
* `rustc_trans::trans::*` to `rustc_trans::*`
* `rustc_trans::save` to `rustc_save_analysis` (cc @nrc)
I've rebased a larger WIP branch on top of this and the only conflicts were in imports, but YMMV.
std: Rewrite Once with poisoning
This commit rewrites the `std::sync::Once` primitive with poisoning in mind in
light of #31688. Currently a panic in the initialization closure will cause
future initialization closures to run, but the purpose of a Once is usually to
initialize some global state so it's highly likely that the global state is
corrupt if a panic happened. The same strategy of a mutex is taken where a panic
is propagated by default.
A new API, `call_once_force`, was added to subvert panics like is available on
Mutex as well (for when panicking is handled internally).
Adding this support was a significant enough change to the implementation that
it was just completely rewritten from scratch, primarily to avoid using a
`StaticMutex` which needs to have `destroy()` called on it at some point (a pain
to do).
Closes#31688
This commit rewrites the `std::sync::Once` primitive with poisoning in mind in
light of #31688. Currently a panic in the initialization closure will cause
future initialization closures to run, but the purpose of a Once is usually to
initialize some global state so it's highly likely that the global state is
corrupt if a panic happened. The same strategy of a mutex is taken where a panic
is propagated by default.
A new API, `call_once_force`, was added to subvert panics like is available on
Mutex as well (for when panicking is handled internally).
Adding this support was a significant enough change to the implementation that
it was just completely rewritten from scratch, primarily to avoid using a
`StaticMutex` which needs to have `destroy()` called on it at some point (a pain
to do).
Closes#31688
Avoid page reload upon hitting "S" when browsing documentation in local mode
The problem seems to have been introduced with commit 2910c0020661304df237fb8ed646296304c8e0d2
Add note on `str` being an unsized type in strings section of book
The book section on Rust strings mentions `&str` and `String` but does not address why `str` is not used directly. This adds a short blurb and a link to the unsized types chapter. The second draft of the book will go more in-depth on this, but this should help a bit for now. Thanks #rust for clarifying this point, and let me know if it needs rewording or different placement 😄.
CC @steveklabnik @Kimundi
Document heap allocation location guarantee
```
14:25 < aidanhs> is there any guarantee that boxes will not move the value on the heap when they are moved?
14:26 <@steveklabnik> aidanhs: ... i'm not sure if it's a guarantee, but it follows, generally
14:26 <@steveklabnik> aidanhs: moves mean memcpy, so you're memcpying the structure of the box itself, which is copying the pointer
14:26 <@steveklabnik> so the pointer won't be updated
14:26 <@steveklabnik> moves cannot do complex things like move the memory around on the heap
14:26 <@kmc> aidanhs: I would say it's guaranteed
14:27 < aidanhs> steveklabnik: yeah, that's what I was thinking, it'd be pretty strange for rust to do something, but I couldn't find any docs one way or the other
14:27 <@steveklabnik> kmc: aidanhs yeah, it's like a borderline thing that we don't explicitly guanratee but i think IS guaranteed by our other guarantees
14:27 <@steveklabnik> mostly that move == memcpy
14:28 < aidanhs> kmc: steveklabnik great thanks! would a PR to the rust reference along these lines be ok?
14:28 < jmesmon> aidanhs: I believe owning_ref has some discussion of that (stable references)
14:29 <@steveklabnik> aidanhs: i would probably take that, yeah
14:29 < aidanhs> jmesmon: thanks, I'll take a look at that
```
https://botbot.me/mozilla/rust/2016-02-22/?msg=60657619&page=18
r? @steveklabnik
