Mark Arc function get_mut and method make_unique unsafe
This is a temporary mitigation for issue #24880 which points out that
these functions are racy in a particular situation where weak pointers
exist.
To mitigate this, mark the functions unsafe until this can be fixed or
another decision is made.
The `HashMap` and `HashSet` iterators use `RawTable::first_bucket_raw` which is generic and will get inlined cross-crate.
However, `first_bucket_raw` calls `calculate_offsets` and the call doesn't get inlined, despite being a simple function.
This missing `#[inline]` results in `hash_table::calculate_offsets` showing up at the top of a callgrind profile with 3 million calls (for the testcase in #25916).
This is a temporary mitigation for issue #24880 which points out that
these functions are racy in a particular situation where weak pointers
exist.
To mitigate this, mark the functions unsafe until this can be fixed or
another decision is made.
This is a breaking change to unstable API, because the new version
requires an `unsafe` block. Review carefully if weak pointers may race
for any uses of this API and consider abandoning it.
[breaking-change]
GDB and LLDB pretty printers have some common functionality
and also access some common information, such as the layout of
standard library types. So far, this information has been
duplicated in the two pretty printing python modules. This
commit introduces a common module used by both debuggers.
The E0397 explanation, as I've written it, isn't really an explanation, but I'm not sure what to put here. I will happily take suggestions.
Partially addresses https://github.com/rust-lang/rust/issues/25851
This adds an example from mem::swap, and provides some suggested uses of this
function.
This is my attempt to summarize the answers to a question I asked on reddit http://www.reddit.com/r/rust/comments/37jcul/what_is_forget_for/ and add the answers to the documentation so that no one else has to google or ask the question again.
This commit implements a number of standard traits for the standard library's
process I/O handles. The `FromRaw{Fd,Handle}` traits are now implemented for the
`Stdio` type and the `AsRaw{Fd,Handle}` traits are now implemented for the
`Child{Stdout,Stdin,Stderr}` types.
The stability markers for these implementations mention that they are stable for
1.1 as I will nominate this commit for cherry-picking to beta.
This takes the cases from InvalidInput where a data format error
was encountered. This is different from the documented semantics
of InvalidInput, which more likely indicate a programming error.
This adds an example from mem::swap, and provides some suggested uses of this
function.
Change wording on comment on forget line to be more specific as to why we
need to call forget.
This breaks the examples up into three pieces. The last piece isn't
compiling for some reason.
The previous feature gate assumed we would not define any (stable) const fns. But then @eddyb went and cleaned up the code. So this now extends the feature-gate to prohibit calls; but calls inside of macros are considered ok.
r? @alexcrichton
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.
Windows tests can often deadlock if a child thread continues after the main
thread and then panics, and a `println!` executed in a child thread after the
main thread has exited is at risk of panicking.
Windows tests can often deadlock if a child thread continues after the main
thread and then panics, and a `println!` executed in a child thread after the
main thread has exited is at risk of panicking.
The current codegen tests only compare IR line counts between similar
rust and C programs, the latter getting compiled with clang. That looked
like a good idea back then, but actually things like lifetime intrinsics
mean that less IR isn't always better, so the metric isn't really
helpful.
Instead, we can start doing tests that check specific aspects of the
generated IR, like attributes or metadata. To do that, we can use LLVM's
FileCheck tool which has a number of useful features for such tests.
To start off, I created some tests for a few things that were recently
added and/or broken.
The current codegen tests only compare IR line counts between similar
rust and C programs, the latter getting compiled with clang. That looked
like a good idea back then, but actually things like lifetime intrinsics
mean that less IR isn't always better, so the metric isn't really
helpful.
Instead, we can start doing tests that check specific aspects of the
generated IR, like attributes or metadata. To do that, we can use LLVM's
FileCheck tool which has a number of useful features for such tests.
To start off, I created some tests for a few things that were recently
added and/or broken.
Currently, for `use` declarations with multiple paths, only the `use` item itself is saved in the AST map, not the individual path nodes. This can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in `ImportResolver::check_for_conflicting_import()`.
Fixes#25763.
Needed to support:
```rust
match X {
pattern if Y ...
}
for pattern in Y {}
```
IMO, this shouldn't require an RFC because it can't interfere with any future language changes (because `pattern if` and `pattern in` are already legal in rust) and can't cause any ambiguity.
- Adds explanations for E0055, E0089, E0192, E0261-E0263, E0318
- Improves explanations for E0250, E0368, E0372.
- Converts 15 diagnostics to have error codes (E0380-E0394). Adds an explanation for E0380.
- The E0087-E0090 messages currently look like "expected {} parameter(s) found {} parameter(s)". This changes them to either use "parameter" or "parameters", based on the number.
This is, in part, more progress towards #24407
rustdoc: Associated type fixes
The first commit fixes a bug with "dud" items in the search index from
misrepresented `type` items in trait impl blocks.
For a trait *implementation* there are typedefs which are the types for
that particular trait and implementor. Skip these in the search index.
There were lots of dud items in the search index due to this (search for
Item, Iterator's associated type).
Add a boolean to clean::TypedefItem so that it tracks whether the it is
a type alias on its own, or if it's a `type` item in a trait impl.
The second commit fixes a bug that made signatures and where bounds
using associated types (if they were not on `Self`) incorrect.
The third commit fixes so that where clauses in type alias definititons
are shown.
Fixes#22442Fixes#24417Fixes#25769
Changes:
- adds explanations for E0185, E0186, E0202, E0326
- fixes the explanation for E0053. The previous description was too narrow; there are other error cases.
- changes the error message for E0202 to be specific for associated types, since it seems inherent associated constants are implemented.
Part of #24407
Closes#25046 (by rejecting the code that causes the ICE) and #24946. I haven't been able to deal with the array size or recursion issues yet for associated consts, though my hope was that the change I made for range match patterns might help with array sizes, too.
This PR is pretty much orthogonal to #25065.
