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.
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.
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.
'work' can refer to the game itself, ie, 'this compiles but the game isn't finished,'
so 'compile' is a more clear way to describe the problem.
Thanks jhun on irc
'work' can refer to the game itself, ie, 'this compiles but the game isn't finished,'
so 'compile' is a more clear way to describe the problem.
Thanks jhun on irc
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)
r? @nikomatsakis
