Replace many uses of `mem::transmute` with more specific functions
The replacements are functions that usually use a single `mem::transmute` in
their body and restrict input and output via more concrete types than `T` and
`U`. Worth noting are the `transmute` functions for slices and the `from_utf8*`
family for mutable slices. Additionally, `mem::transmute` was often used for
casting raw pointers, when you can already cast raw pointers just fine with
`as`.
bors [Sat, 8 Aug 2015 16:27:12 +0000 (16:27 +0000)]
Auto merge of #27595 - mike-marcacci:patch-1, r=steveklabnik
Keeping integer values and integer references in the "value" columns made the examples quite difficult for me to follow. I've added unicode arrows to references to make them more obvious, without using any characters with actual meaning in the rust language (like `&` or previously `~`).
Mike Marcacci [Sat, 8 Aug 2015 06:13:08 +0000 (23:13 -0700)]
Added arrows to references in tables
Keeping integer values and integer references in the "value" columns made the examples quite difficult for me to follow. I've added unicode arrows to make references more obvious, without using a character with actual meaning in the rust language (like `&` or previously `~`).
This is a temporary workaround for the bugs that have been found in
the implementation of PR #26173.
* pnkfelix is unavailable in the short-term (i.e. for the next week) to fix them.
* When the bugs are fixed, we will turn this back on by default.
(If you want to play with the known-to-be-buggy optimization in the
meantime, you can opt-back in via the debugging option that this
commit is toggling.)
bors [Fri, 7 Aug 2015 12:23:06 +0000 (12:23 +0000)]
Auto merge of #27551 - arielb1:adt-def, r=nikomatsakis
This ended up being a bigger refactoring than I thought, as I also cleaned a few ugly points in rustc. There are still a few areas that need improvements.
bors [Thu, 6 Aug 2015 20:45:39 +0000 (20:45 +0000)]
Auto merge of #27566 - rubymeow:master, r=steveklabnik
I got a bit confused reading the guide over why all of a sudden there was an asterisk in the code. I was explained what it was there for in the IRC, and I think it should added it to the docs to prevent any further confusion!
bors [Thu, 6 Aug 2015 19:11:17 +0000 (19:11 +0000)]
Auto merge of #27296 - jroesch:type-macros, r=huonw
This pull request implements the functionality for [RFC 873](https://github.com/rust-lang/rfcs/blob/master/text/0873-type-macros.md). This is currently just an update of @freebroccolo's branch from January, the corresponding commits are linked in each commit message.
@nikomatsakis and I had talked about updating the macro language to support a lifetime fragment specifier, and it is possible to do that work on this branch as well. If so we can (collectively) talk about it next week during the pre-RustCamp work week.
bors [Thu, 6 Aug 2015 15:01:35 +0000 (15:01 +0000)]
Auto merge of #27434 - jeehoonkang:master, r=Gankro
In Section 3.2, TARPL says that "standard allocators (including jemalloc, the one used by default in Rust) generally consider passing in 0 for the size of an allocation as Undefined Behaviour."
However, the C standard and jemalloc manual says allocating zero bytes
should succeed:
- C11 7.22.3 paragraph 1: "If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object."
- [jemalloc manual](http://www.freebsd.org/cgi/man.cgi?query=jemalloc&sektion=3): "The malloc and calloc functions return a pointer to the allocated memory if successful; otherwise a NULL pointer is returned and errno is set to ENOMEM."
+ Note that the description for `allocm` says "Behavior is undefined if size is 0," but it is an experimental API.
Jeehoon Kang [Fri, 31 Jul 2015 14:55:01 +0000 (23:55 +0900)]
Revise TARPL's description for allocating 0 bytes
In Section 3.2, TARPL says that "standard allocators (including jemalloc, the one used by default in Rust) generally consider passing in 0 for the size of an allocation as Undefined Behaviour."
However, the C standard and jemalloc manual says allocating zero bytes
should succeed:
- C11 7.22.3 paragraph 1: "If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object."
- [jemalloc manual](http://www.freebsd.org/cgi/man.cgi?query=jemalloc&sektion=3): "The malloc and calloc functions return a pointer to the allocated memory if successful; otherwise a NULL pointer is returned and errno is set to ENOMEM."
+ Note that the description for `allocm` says "Behavior is undefined if size is 0," but it is an experimental API.
bors [Thu, 6 Aug 2015 03:40:42 +0000 (03:40 +0000)]
Auto merge of #27545 - apasel422:btree-range, r=Gankro
This permits collections with `String` keys to be ranged over with
`&str` bounds. The `K` defaults for `Min` and `Max` permit the default
type parameter fallback to work with things like
```rust
use std::collections::{BTreeSet, Bound};
let set = BTreeSet::<String>::new();
set.range(Bound::Included("a"), Bound::Unbounded);
```
Without the defaults, the type of the maximum bound would be
unconstrained.
Fully generalize `BTree{Map, Set}` range iterators
This permits collections with `String` keys to be ranged over with
`&str` bounds. The `K` defaults for `Min` and `Max` permit the default
type parameter fallback to work with things like
```rust
use std::collections::{BTreeSet, Bound};
let set = BTreeSet::<String>::new();
set.range(Bound::Included("a"), Bound::Unbounded);
```
Without the defaults, the type of the maximum bound would be
unconstrained.
Unfortunately these [tests are failing](http://buildbot.rust-lang.org/builders/nightly-dist-rustc-linux/builds/224/steps/distcheck/logs/stdio) on the snapshot/nightly bots with the [same message](https://gist.github.com/alexcrichton/611705ded07b0d73ded9) found in #27514
bors [Wed, 5 Aug 2015 10:30:41 +0000 (10:30 +0000)]
Auto merge of #27458 - mitaa:local_cpath, r=nikomatsakis
This changes the current behaviour for two cases (that I know of)
```rust
mod foo {
extern crate bar;
}
// `bar::` changes to `foo::bar::`
```
```rust
extern crate bar as quux;
// `bar::` changes to `quux::`
```
For example:
```rust
mod foo {
extern crate core;
}
fn assert_clone<T>() where T : Clone { }
fn main() {
assert_clone::<foo::core::atomic::AtomicBool>();
// error: the trait `core::clone::Clone` is not implemented for the type `core::atomic::AtomicBool` [E0277]
// changes to
// error: the trait `foo::core::clone::Clone` is not implemented for the type `foo::core::atomic::AtomicBool` [E0277]
}
```
Notably the following test case broke:
```rust
#[bench]
fn bar(x: isize) { }
//~^ ERROR mismatched types
//~| expected `fn(&mut test::Bencher)`
// changed to
//~| expected `fn(&mut __test::test::Bencher)`
```
If a crate is linked multiple times the path with the least segments is stored.
Partially addresses #1920. (this doesn't solve the issue raised about re-exports)
Rollup merge of #27521 - steveklabnik:doc_std_mem_forget, r=gankro
We were burying the reason to use this function below a bunch of caveats about
its usage. That's backwards. Why a function should be used belongs at the top of
the docs, not the bottom.
Also, add some extra links to related functions mentioned in the body.
Rollup merge of #27519 - JanLikar:rearrange-patterns, r=steveklabnik
- Move "Destructuring" after "Multiple patterns", because some of
later sections include examples which make use of destructuring.
- Move "Ignoring bindings" after "Destructoring", because the former
features Result<T,E> destructuring. Some of examples in later
sections use "_" and "..", so "Ignoring bindings" must be
positioned before them.
- Fix #27347 by moving "Ref and mut ref" before "Ranges" and
"Bindings", because "Bindings" section includes a somewhat
difficult example, which also makes use of "ref" and "mut ref"
operators.
bors [Wed, 5 Aug 2015 07:14:47 +0000 (07:14 +0000)]
Auto merge of #27503 - c-nixon:master, r=steveklabnik
I was reading through the docs and came across a section that felt awkward.
I've tried to improve the flow by splitting up and reversing the explanations of
Arc and Mutex with some example code in between.
The "This would have have happened" bit is unfortunate but I couldn't see any
other way to illustrate it. The compiler errors didn't really help tell the
story in this particular instance so it still feels a bit forced. However I do think it's
an a small improvement...
Does anyone have any other ideas that might flow better?
bors [Wed, 5 Aug 2015 05:37:47 +0000 (05:37 +0000)]
Auto merge of #27520 - brson:bump, r=alexcrichton
This probably wants to go in tomorrow. If it lands today then there will be one day where nightly is on 1.4 and stable is still on 1.1. Not a big deal either way.
bors [Wed, 5 Aug 2015 03:52:39 +0000 (03:52 +0000)]
Auto merge of #27439 - vberger:more_perseverant_resolve, r=nrc
(This is a second try at #26242. This time I think things should be ok.)
The current algorithm handling import resolutions works sequentially, handling imports in the order they appear in the source file, and blocking/bailing on the first one generating an error/being unresolved.
This can lead to situations where the order of the `use` statements can make the difference between "this code compiles" and "this code fails on an unresolved import" (see #18083 for example). This is especially true when considering glob imports.
This PR changes the behaviour of the algorithm to instead try to resolve all imports in a module. If one fails, it is recorded and the next one is tried (instead of directly giving up). Also, all errors generated are stored (and not reported directly).
The main loop of the algorithms guaranties that the algorithm will always finish: if a round of resolution does not resolve anything new, we are stuck and give up. At this point, the new version of the algorithm will display all errors generated by the last round of resolve. This way we are sure to not silence relevant errors or help messages, but also to not give up too early.
**As a consequence, the import resolution becomes independent of the order in which the `use` statements are written in the source files.** I personally don't see any situations where this could be a problem, but this might need some thought.
I passed `rpass` and `cfail` tests on my computer, and now am compiling a full stage2 compiler to ensure the crates reporting errors in my previous attempts still build correctly. I guess once I have checked it, this will need a crater run?
bors [Wed, 5 Aug 2015 02:00:46 +0000 (02:00 +0000)]
Auto merge of #27393 - alexcrichton:no-std-changes, r=brson
This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of
the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The
`#![no_std]` attribute now injects `extern crate core` at the top of the crate
as well as the libcore prelude into all modules (in the same manner as the
standard library's prelude). The `#![no_core]` attribute disables both std and
core injection.