For slightly complex data structures like `rustc_serialize::json::Json`, it is often convenient to have helper methods like `Json::as_string(&self) -> Option<&str>` that return a borrow of some component of `&self`.
However, when `RefCell`s are involved, keeping a `Ref` around is required to hold a borrow to the insides of a `RefCell`. But `Ref` so far only references the entirety of the contents of a `RefCell`, not a component. But there is no reason it couldn’t: `Ref` internally contains just a data reference and a borrow count reference. The two can be dissociated.
This adds a `map_ref` function that creates a new `Ref` for some other data, but borrowing the same `RefCell` as an existing `Ref`.
Example:
```rust
struct RefCellJson(RefCell<Json>);
impl RefCellJson {
fn as_string(&self) -> Option<Ref<str>> {
map_ref(self.borrow(), |j| j.as_string())
}
}
```
r? @alexcrichton
The first commit simply forwards `io::Error`'s `cause` implementation to the inner error.
The second commit adds accessor methods for the inner error. Method names mirror those used elsewhere like `BufReader`.
r? @alexcrichton
The compiler already has special support for fixing up verbatim paths with disks
on Windows to something that can be correctly passed down to gcc, and this
commit adds support for verbatim UNC paths as well.
Closes#25505
The current version of hoedown treats lists interrupting paragraphs in the Markdown.pl style rather than CommonMark, so a newline is needed for the list to be rendered properly.
`core::cell::Cell<T>` and `core::cell::RefCell<T>` currently implement `PartialEq` when `T` does, and just defer to comparing `T` values. There is no reason the same shouldn’t apply to `Eq`.
This enables `#[derive(Eq, PartialEq)]` on e.g. structs that have a `RefCell` field.
r? @alexcrichton
I’m unsure what to do with `#[stable]` attributes on `impl`s. `impl`s generated by `#[derive]` don’t have them.
collections: Make BinaryHeap panic safe in sift_up / sift_down
Use a struct called Hole that keeps track of an invalid location
in the vector and fills the hole on drop.
I include a run-pass test that the current BinaryHeap fails, and the new
one passes.
NOTE: The BinaryHeap will still be inconsistent after a comparison fails. It will
not have the heap property. What we fix is just that elements will be valid
values.
This is actually a performance win -- the new code does not bother to write in `zeroed()`
values in the holes, it just leaves them as they were.
Net result is something like a 5% decrease in runtime for `BinaryHeap::from_vec`. This
can be further improved by using unchecked indexing (I confirmed it makes a difference,
not a surprise with the non-sequential access going on), but let's leave that for another PR.
Safety first 😉Fixes#25842
Use a struct called Hole that keeps track of an invalid location
in the vector and fills the hole on drop.
I include a run-pass test that the current BinaryHeap fails, and the new
one passes.
Fixes#25842
This commit adds a ./configure option called `--disable-elf-tls` which disables
ELF based TLS (that which is communicated to LLVM) on platforms which already
support it. OSX 10.6 does not support this form of TLS, and some users of Rust
need to target 10.6 and are unable to do so due to the usage of TLS. The
standard library will continue to use ELF based TLS on OSX by default (as the
officially supported platform is 10.7+), but this adds an option to compile the
standard library in a way that is compatible with 10.6.
Now that MSVC support has landed in the most recent nightlies we can now have
MSVC bootstrap itself without going through a GNU compiler first. Unfortunately,
however, the bootstrap currently fails due to the compiler not being able to
find the llvm-ar.exe tool during the stage0 libcore compile. The compiler cannot
find this tool because it's looking inside a directory that does not exist:
$SYSROOT/rustlib/x86_64-pc-windows-gnu/bin
The `gnu` on this triple is because the bootstrap compiler's host architecture
is GNU. The build system, however, only arranges for the llvm-ar.exe tool to be
available in this location:
$SYSROOT/rustlib/x86_64-pc-windows-msvc/bin
To resolve this discrepancy, the build system has been modified to understand
triples that are bootstrapped from another triple, and in this case copy the
native tools to the right location.
