bors [Mon, 10 Aug 2015 23:40:54 +0000 (23:40 +0000)]
Auto merge of #27338 - alexcrichton:remove-morestack, r=brson
This commit removes all morestack support from the compiler which entails:
* Segmented stacks are no longer emitted in codegen.
* We no longer build or distribute libmorestack.a
* The `stack_exhausted` lang item is no longer required
The only current use of the segmented stack support in LLVM is to detect stack
overflow. This is no longer really required, however, because we already have
guard pages for all threads and registered signal handlers watching for a
segfault on those pages (to print out a stack overflow message). Additionally,
major platforms (aka Windows) already don't use morestack.
This means that Rust is by default less likely to catch stack overflows because
if a function takes up more than one page of stack space it won't hit the guard
page. This is what the purpose of morestack was (to catch this case), but it's
better served with stack probes which have more cross platform support and no
runtime support necessary. Until LLVM supports this for all platform it looks
like morestack isn't really buying us much.
cc #16012 (still need stack probes)
Closes #26458 (a drive-by fix to help diagnostics on stack overflow)
Alex Crichton [Mon, 27 Jul 2015 20:41:35 +0000 (13:41 -0700)]
Remove morestack support
This commit removes all morestack support from the compiler which entails:
* Segmented stacks are no longer emitted in codegen.
* We no longer build or distribute libmorestack.a
* The `stack_exhausted` lang item is no longer required
The only current use of the segmented stack support in LLVM is to detect stack
overflow. This is no longer really required, however, because we already have
guard pages for all threads and registered signal handlers watching for a
segfault on those pages (to print out a stack overflow message). Additionally,
major platforms (aka Windows) already don't use morestack.
This means that Rust is by default less likely to catch stack overflows because
if a function takes up more than one page of stack space it won't hit the guard
page. This is what the purpose of morestack was (to catch this case), but it's
better served with stack probes which have more cross platform support and no
runtime support necessary. Until LLVM supports this for all platform it looks
like morestack isn't really buying us much.
cc #16012 (still need stack probes)
Closes #26458 (a drive-by fix to help diagnostics on stack overflow)
bors [Mon, 10 Aug 2015 18:46:21 +0000 (18:46 +0000)]
Auto merge of #27252 - tbu-:pr_less_transmutes, r=alexcrichton
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 [Mon, 10 Aug 2015 17:06:15 +0000 (17:06 +0000)]
Auto merge of #27516 - alexcrichton:osx-flaky-zomg, r=brson
The investigation into #14232 discovered that it's possible that signal delivery
to a newly spawned process is racy on OSX. This test has been failing spuriously
on the OSX bots for some time now, so ignore it as we don't currently know a
solution and it looks like it may be out of our control.
bors [Mon, 10 Aug 2015 14:40:07 +0000 (14:40 +0000)]
Auto merge of #27547 - vberger:more_perseverant_resolve, r=nrc
As noted in my previous PR #27439 , the import resolution algorithm has two cases where it bails out:
- The algorithm will delay an import if the module containing the target of the import still has unresolved glob imports
- The algorithm will delay a glob import of the target module still has unresolved imports
This PR alters the behaviour to only bail out when the above described unresolved imports are `pub`, as non-pub imports don't affect the result anyway.
It is still possible to fail the algorithm with examples like
```rust
pub mod a {
pub use b::*;
}
pub mod b {
pub use a::*;
}
```
but such configurations cannot be resolved in any meaningful way, as these are cyclic imports.
bors [Mon, 10 Aug 2015 12:01:01 +0000 (12:01 +0000)]
Auto merge of #27634 - TimNN:master, r=dotdash
I don't know how this single inline caused the breakage but it seems to be the cause of the issue (see https://github.com/rust-lang/rust/issues/27619#issuecomment-129420094).
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
projects / rust.git / log