bors [Wed, 27 Nov 2013 23:32:18 +0000 (15:32 -0800)]
auto merge of #10642 : cmr/rust/strict_doccomment, r=alexcrichton
Previously, `//// foo` and `/*** foo ***/` were accepted as doc comments. This
changes that, so that only `/// foo` and `/** foo ***/` are accepted. This
confuses many newcomers and it seems weird.
Also update the manual for these changes, and modernify the EBNF for comments.
Corey Richardson [Mon, 25 Nov 2013 04:23:50 +0000 (23:23 -0500)]
Be more strict about doc comments
Previously, `//// foo` and `/*** foo ***/` were accepted as doc comments. This
changes that, so that only `/// foo` and `/** foo ***/` are accepted. This
confuses many newcomers and it seems weird.
Also update the manual for these changes, and modernify the EBNF for comments.
bors [Wed, 27 Nov 2013 22:17:41 +0000 (14:17 -0800)]
auto merge of #10680 : alexcrichton/rust/relax-feature-gate, r=thestinger
Instead of forcibly always aborting compilation, allow usage of
#[warn(unknown_features)] and related lint attributes to selectively abort
compilation. By default, this lint is deny.
bors [Wed, 27 Nov 2013 17:57:05 +0000 (09:57 -0800)]
auto merge of #10662 : alexcrichton/rust/thread-detach, r=pcwalton
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).
Alex Crichton [Tue, 26 Nov 2013 22:55:06 +0000 (14:55 -0800)]
Relax restrictions on unknown feature directives
Instead of forcibly always aborting compilation, allow usage of
#[warn(unknown_features)] and related lint attributes to selectively abort
compilation. By default, this lint is deny.
Alex Crichton [Tue, 26 Nov 2013 02:08:31 +0000 (18:08 -0800)]
Improve the rt::thread module
* 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'
bors [Wed, 27 Nov 2013 09:52:10 +0000 (01:52 -0800)]
auto merge of #10688 : bjz/rust/recv_iter, r=brson
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.
bors [Wed, 27 Nov 2013 06:07:44 +0000 (22:07 -0800)]
auto merge of #10670 : eddyb/rust/node-u32, r=alexcrichton
### 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**.
Alex Crichton [Tue, 26 Nov 2013 02:27:27 +0000 (18:27 -0800)]
Clean up statically initialized data on shutdown
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.
bors [Tue, 26 Nov 2013 22:52:05 +0000 (14:52 -0800)]
auto merge of #10649 : sfackler/rust/multi-macro, r=alexcrichton
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.
bors [Tue, 26 Nov 2013 17:17:58 +0000 (09:17 -0800)]
auto merge of #10664 : alexcrichton/rust/issue-10663, r=luqmana
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.
Alex Crichton [Tue, 26 Nov 2013 05:59:08 +0000 (21:59 -0800)]
Correctly handle libuv errors in addrinfo calls
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.
bors [Tue, 26 Nov 2013 10:52:04 +0000 (02:52 -0800)]
auto merge of #10660 : alexcrichton/rust/little-scope, r=pcwalton
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).
bors [Tue, 26 Nov 2013 09:07:40 +0000 (01:07 -0800)]
auto merge of #10622 : Kimundi/rust/str_de_iter, r=alexcrichton
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:
... 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.
bors [Tue, 26 Nov 2013 07:02:29 +0000 (23:02 -0800)]
auto merge of #10631 : klutzy/rust/win-fixes, r=alexcrichton
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.
bors [Tue, 26 Nov 2013 05:47:16 +0000 (21:47 -0800)]
auto merge of #10316 : klutzy/rust/attr-lint, r=cmr
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.
Alex Crichton [Tue, 26 Nov 2013 01:55:41 +0000 (17:55 -0800)]
Move LittleLock to using RAII
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).
bors [Mon, 25 Nov 2013 13:46:37 +0000 (05:46 -0800)]
auto merge of #10646 : alexcrichton/rust/issue-10645, r=luqmana
This is a behavioral difference in libuv between different platforms in
different situations. It turns out that libuv on windows will immediately
allocate a buffer instead of waiting for data to be ready. What this implies is
that we must have our custom data set on the handle before we call
uv_read_start.
I wish I knew of a way to test this, but this relies to being on the windows
platform *and* reading from a true TTY handle which only happens when this is
actually attached to a terminal. I have manually verified this works.
Niko Matsakis [Sat, 16 Nov 2013 22:29:19 +0000 (17:29 -0500)]
Add [mut_]shift_ref/[mut_]pop_ref functions, which return a pointer to the first/last item in the slice and modify the slice to exclude the returned item. Useful when writing iterators over mutable references.
bors [Mon, 25 Nov 2013 07:56:46 +0000 (23:56 -0800)]
auto merge of #10641 : cmr/rust/close_delims, r=alexcrichton
Currently, the parser doesn't give any context when it finds an unclosed
delimiter and it's not EOF. Report the most recent unclosed delimiter, to help
the user along.
bors [Mon, 25 Nov 2013 06:47:10 +0000 (22:47 -0800)]
auto merge of #10635 : alexcrichton/rust/issue-10626, r=cmr
This is both useful for performance (otherwise logging is unbuffered), but also
useful for correctness. Because when a task is destroyed we can't block the task
waiting for the logger to close, loggers are opened with a 'CloseAsynchronously'
specification. This causes libuv do defer the call to close() until the next
turn of the event loop.
If you spin in a tight loop around printing, you never yield control back to the
libuv event loop, meaning that you simply enqueue a large number of close
requests but nothing is actually closed. This queue ends up never getting
closed, meaning that if you keep trying to create handles one will eventually
fail, which the runtime will attempt to print the failure, causing mass
destruction.
Caching will provide better performance as well as prevent creation of too many
handles.