This has one commit from a separate pull request (because these commits depend on that one), but otherwise the extra details can be found in the commit messages. The `rt::thread` module has been generally cleaned up for everyday safe usage (and it's a bug if it's not safe).
* Added doc comments explaining what all public functionality does.
* Added the ability to spawn a detached thread
* Added the ability for the procs to return a value in 'join'
I've noticed I use this pattern quite a bit:
~~~rust
do spawn {
loop {
match port.try_recv() {
Some(x) => ...,
None => ...,
}
}
}
~~~
The `RecvIterator`, returned from a default `recv_iter` method on the `GenericPort` trait, allows you to reduce this down to:
~~~rust
do spawn {
for x in port.recv_iter() {
...
}
}
~~~
As demonstrated in the tests, you can also access the port from within the `for` block for further `recv`ing and `peek`ing with no borrow errors, which is quite nice.
### Rationale
There is no reason to support more than 2³² nodes or names at this moment, as compiling something that big (even without considering the quadratic space usage of some analysis passes) would take at least **64GB**.
Meanwhile, some can't (or barely can) compile rustc because it requires almost **1.5GB**.
### Potential problems
Can someone confirm this doesn't affect metadata (de)serialization? I can't tell myself, I know nothing about it.
### Results
Some structures have a size reduction of 25% to 50%: [before](https://gist.github.com/luqmana/3a82a51fa9c86d9191fa) - [after](https://gist.github.com/eddyb/5a75f8973d3d8018afd3).
Sadly, there isn't a massive change in the memory used for compiling stage2 librustc (it doesn't go over **1.4GB** as [before](http://huonw.github.io/isrustfastyet/mem/), but I can barely see the difference).
However, my own testcase (previously peaking at **1.6GB** in typeck) shows a reduction of **200**-**400MB**.
Whenever the runtime is shut down, add a few hooks to clean up some of the
statically initialized data of the runtime. Note that this is an unsafe
operation because there's no guarantee on behalf of the runtime that there's no
other code running which is using the runtime.
This helps turn down the noise a bit in the valgrind output related to
statically initialized mutexes. It doesn't turn the noise down to 0 because
there are still statically initialized mutexes in dynamic_lib and
os::with_env_lock, but I believe that it would be easy enough to add exceptions
for those cases and I don't think that it's the runtime's job to go and clean up
that data.
The majority of this change is modifying some of the `ast_visit` methods to return multiple values.
It's prohibitively expensive to allocate a `~[Foo]` every time a statement, declaration, item, etc is visited, especially since the vast majority will have 0 or 1 elements. I've added a `SmallVector` class that avoids allocation in the 0 and 1 element cases to take care of that.
It turns out that libuv was returning ENOSPC to us in our usage of the
uv_ipX_name functions. It also turns out that there may be an off-by-one in
libuv. For now just add one to the buffer size and handle the return value
correctly.
Closes#10663
It turns out that libuv was returning ENOSPC to us in our usage of the
uv_ipX_name functions. It also turns out that there may be an off-by-one in
libuv. For now just add one to the buffer size and handle the return value
correctly.
Closes#10663
This moves the locking/waiting methods to returning an RAII struct instead of
relying on closures. Additionally, this changes the methods to all take
'&mut self' to discourage recursive locking. The new method to block is to call
`wait` on the returned RAII structure instead of calling it on the lock itself
(this enforces that the lock is held).
At the same time, this improves the Mutex interface a bit by allowing
destruction of non-initialized members and by allowing construction of an empty
mutex (nothing initialized inside).
This PR removes almost all `_iter` suffixes in various APIs of the codebase that return Iterators, as discussed in #9440.
As a summarize for the intend behind this PR:
- Iterators are the recommended way to provide a potentially lazy list of values, no need to name them painfully verbose. If anything, functions that return a specific container type should have more verbose names.
- We have a static type system, so no need to encode the return value of a constructor function into its name.
Following is a possibly incomplete list of all renamings I performed in the codebase. For a few of them I'm a bit unsure whether the new name still properly expresses their functionality, so feedback would be welcome:
~~~
&str : word_iter() -> words()
line_iter() -> lines()
any_line_iter() -> lines_any()
iter() -> chars()
char_offset_iter() -> char_indices()
byte_iter() -> bytes()
split_iter() -> split()
splitn_iter() -> splitn()
split_str_iter() -> split_str()
split_terminator_iter() -> split_terminator()
matches_index_iter() -> match_indices()
nfd_iter() -> nfd_chars()
nfkd_iter() -> nfkd_chars()
&[T] : split_iter() -> split()
splitn_iter() -> splitn()
window_iter() -> windows()
chunk_iter() -> chunks()
permutations_iter() -> permutations()
extra:bitv::Bitv : rev_liter() -> rev_iter()
common_iter() -> commons()
outlier_iter() -> outliers()
extra::treemap::{...} : lower_bound_iter() -> lower_bound()
upper_bound_iter() -> upper_bound()
std::trie::{...} : bound_iter() -> bound()
lower_bound_iter() -> lower_bound()
upper_bound_iter() -> upper_bound()
rustpkg::package_id::{...} : prefixes_iter() -> prefixes()
std::hashmap::{...} : difference_iter() -> difference()
symmetric_difference_iter() -> symmetric_difference()
intersection_iter() -> intersection()
union_iter() -> union()
std::path::{posix, windows} : component_iter() -> components()
str_component_iter() -> str_components()
... not showing all identical renamings for reverse versions
~~~
---
I'm also planning a few more changes, like removing all unnecessary `_rev` constructors (#9391), or reducing the `split` variants on `&str` to a more versatile and concise system.
This patchset fixes some parts broken on Win64.
This also adds `--disable-pthreads` flags to llvm on mingw-w64 archs (both 32-bit and 64-bit, not mingw) due to bad performance. See #8996 for discussion.
This patchset makes warning if crate-level attribute is used at other places, obsolete attributed is used, or unknown attribute is used, since they are usually from mistakes.
Closes#3348
