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.
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.
Alex Crichton [Mon, 25 Nov 2013 05:47:13 +0000 (21:47 -0800)]
Set uv's custom data before uv_read_start
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.
bors [Mon, 25 Nov 2013 05:32:13 +0000 (21:32 -0800)]
auto merge of #10603 : alexcrichton/rust/no-linked-failure, r=brson
The reasons for doing this are:
* The model on which linked failure is based is inherently complex
* The implementation is also very complex, and there are few remaining who
fully understand the implementation
* There are existing race conditions in the core context switching function of
the scheduler, and possibly others.
* It's unclear whether this model of linked failure maps well to a 1:1 threading
model
Linked failure is often a desired aspect of tasks, but we would like to take a
much more conservative approach in re-implementing linked failure if at all.
Alex Crichton [Sun, 24 Nov 2013 18:55:17 +0000 (10:55 -0800)]
Cache a task's stderr logger
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.
Alex Crichton [Fri, 22 Nov 2013 00:55:40 +0000 (16:55 -0800)]
Remove linked failure from the runtime
The reasons for doing this are:
* The model on which linked failure is based is inherently complex
* The implementation is also very complex, and there are few remaining who
fully understand the implementation
* There are existing race conditions in the core context switching function of
the scheduler, and possibly others.
* It's unclear whether this model of linked failure maps well to a 1:1 threading
model
Linked failure is often a desired aspect of tasks, but we would like to take a
much more conservative approach in re-implementing linked failure if at all.
bors [Mon, 25 Nov 2013 04:22:03 +0000 (20:22 -0800)]
auto merge of #10639 : jix/rust/fix_find_mut_in_trie, r=thestinger
Make TrieMap/TrieSet's find_mut check the key for external nodes.
Without this find_mut sometimes returns a reference to another key when
querying for a non-present key.
Corey Richardson [Mon, 25 Nov 2013 02:18:20 +0000 (21:18 -0500)]
Add a note for unclosed delimiters
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.
Jannis Harder [Sun, 24 Nov 2013 22:41:33 +0000 (23:41 +0100)]
std::trie: Fix find_mut for non-present keys
Make TrieMap/TrieSet's find_mut check the key for external nodes.
Without this find_mut sometimes returns a reference to another key when
querying for a non-present key.
bors [Sun, 24 Nov 2013 18:17:03 +0000 (10:17 -0800)]
auto merge of #10475 : astrieanna/rust/issue8763, r=alexcrichton
Issue #8763 is about improving a particular error message.
* added case & better error message for "impl trait for module"
* added compile-fail test trait-impl-for-module.rs
* updated copyright dates
* revised compile-fail test trait-or-new-type-instead
(the error message for the modified test is still unclear, but that's a different bug https://github.com/mozilla/rust/issues/8767)
Leah Hanson [Thu, 14 Nov 2013 03:29:37 +0000 (21:29 -0600)]
Fix issue #8763
* added case & better error message for "impl trait for module"
* used better way to print the module
* switched from //error-pattern to //~ ERROR
* added compile-fail test trait-impl-for-module.rs
* revised compile-fail test trait-or-new-type-instead
(the error message for the modified test is still unclear, but that's a different bug)
* added FIXME to trait-or-new-type-instead
bors [Sun, 24 Nov 2013 05:36:50 +0000 (21:36 -0800)]
auto merge of #10578 : luqmana/rust/mingw64, r=alexcrichton
With these changes I was able to cross compile for windows from a linux box. (Using the mingw-w64 package on Debian Testing).
Fixed a bug where the `target_family` cfg would be wrong when targeting something with a different value than the host. (i.e windows -> unix or unix -> windows).
Also, removed `LIBUV_FLAGS` in `mk/rt.mk` because of the redundancy between it and `CFG_GCCISH_CFLAGS_(target)`.
After this we can create a snapshot and migrate to mingw64 instead of mingw32.
bors [Sun, 24 Nov 2013 04:01:42 +0000 (20:01 -0800)]
auto merge of #10514 : sfackler/rust/mut, r=cmr
This is based off of @blake2-ppc's work on #9429. That PR bitrotted and I haven't been able to contact the original author so I decided to take up the cause.
Overview
======
`Mut` encapsulates a mutable, non-nullable slot. The `Cell` type is currently used to do this, but `Cell` is much more commonly used as a workaround for the inability to move values into non-once functions. `Mut` provides a more robust API.
`Mut` duplicates the semantics of borrowed pointers with enforcement at runtime instead of compile time.
```rust
let x = Mut::new(0);
{
// make some immutable borrows
let p = x.borrow();
let y = *p.get() + 10;
// multiple immutable borrows are allowed simultaneously
let p2 = x.borrow();
// this would throw a runtime failure
// let p_mut = x.borrow_mut();
}
// now we can mutably borrow
let p = x.borrow_mut();
*p.get() = 10;
```
`borrow` returns a `Ref` type and `borrow_mut` returns a `RefMut` type, both of which are simple smart pointer types with a single method, `get`, which returns a reference to the wrapped data.
This also allows `RcMut<T>` to be deleted, as it can be replaced with `Rc<Mut<T>>`.
Changes
======
I've done things a little bit differently than the original proposal.
* I've added `try_borrow` and `try_borrow_mut` methods that return `Option<Ref<T>>` and `Option<RefMut<T>>` respectively instead of failing on a borrow check failure. I'm not totally sure when that'd be useful, but I don't see any reason to not put them in and @cmr requested them.
* `ReadPtr` and `WritePtr` have been renamed to `Ref` and `RefMut` respectively, as `Ref` is to `ref foo` and `RefMut` is to `ref mut foo` as `Mut` is to `mut foo`.
* `get` on `MutRef` now takes `&self` instead of `&mut self` for consistency with `&mut`. As @alexcrichton pointed, out this violates soundness by allowing aliasing `&mut` references.
* `Cell` is being left as is. It solves a different problem than `Mut` is designed to solve.
* There are no longer methods implemented for `Mut<Option<T>>`. Since `Cell` isn't going away, there's less of a need for these, and I didn't feel like they provided a huge benefit, especially as that kind of `impl` is very uncommon in the standard library.
Open Questions
============
* `Cell` should now be used exclusively for movement into closures. Should this be enforced by reducing its API to `new` and `take`? It seems like this use case will be completely going away once the transition to `proc` and co. finishes.
* Should there be `try_map` and `try_map_mut` methods along with `map` and `map_mut`?
bors [Fri, 22 Nov 2013 20:41:36 +0000 (12:41 -0800)]
auto merge of #10612 : pnkfelix/rust/remove-cut-and-pasted-rt-fixme, r=pcwalton
I cannot tell whether the original comment was unsure about the
arithmetic calculations, or if it was unsure about the assumptions
being made about the alignment of the current allocation pointer.
The arithmetic calculation looks fine to me, though. This technique
is documented e.g. in Henry Warren's "Hacker's Delight" (section 3-1).
(I am sure one can find it elsewhere too, its not an obscure
property.)
bors [Fri, 22 Nov 2013 18:06:35 +0000 (10:06 -0800)]
auto merge of #10583 : alexcrichton/rust/privacy-reexport, r=pcwalton
I added a test case which does not compile today, and required changes on
privacy's side of things to get right. Additionally, this moves a good bit of
logic which did not belong in reachability into privacy.
All of reachability should solely be responsible for determining what the
reachable surface area of a crate is given the exported surface area (where the
exported surface area is that which is usable by external crates).
Privacy will now correctly figure out what's exported by deeply looking
through reexports. Previously if a module were reexported under another name,
nothing in the module would actually get exported in the executable. I also
consolidated the phases of privacy to be clearer about what's an input to what.
The privacy checking pass no longer uses the notion of an "all public" path, and
the embargo visitor is no longer an input to the checking pass.
Currently the embargo visitor is built as a saturating analysis because it's
unknown what portions of the AST are going to get re-exported.
This also cracks down on exported methods from impl blocks and trait blocks. If you implement a private trait, none of the symbols are exported, and if you have an impl for a private type none of the symbols are exported either. On the other hand, if you implement a public trait for a private type, the symbols are still exported. I'm unclear on whether this last part is correct, but librustc will fail to link unless it's in place.
Alex Crichton [Wed, 20 Nov 2013 23:15:34 +0000 (15:15 -0800)]
Move more of the exportation burden into privacy
I added a test case which does not compile today, and required changes on
privacy's side of things to get right. Additionally, this moves a good bit of
logic which did not belong in reachability into privacy.
All of reachability should solely be responsible for determining what the
reachable surface area of a crate is given the exported surface area (where the
exported surface area is that which is usable by external crates).
Privacy will now correctly figure out what's exported by deeply looking
through reexports. Previously if a module were reexported under another name,
nothing in the module would actually get exported in the executable. I also
consolidated the phases of privacy to be clearer about what's an input to what.
The privacy checking pass no longer uses the notion of an "all public" path, and
the embargo visitor is no longer an input to the checking pass.
Currently the embargo visitor is built as a saturating analysis because it's
unknown what portions of the AST are going to get re-exported.
The original fixme #2699 was removed back in PR #6053.
I cannot tell whether the original comment was unsure about the
arithmetic calculations, or if it was unsure about the assumptions
being made about the alignment of the current allocation pointer.
The arithmetic calculation looks fine to me, though. This technique
is documented e.g. in Henry Warren's "Hacker's Delight" (section 3-1).
(I am sure one can find it elsewhere too, its not an obscure
property.)