auto merge of #13845 : alexcrichton/rust/regex-deps, r=brson
There is currently not much precedent for target crates requiring syntax
extensions to compile their test versions. This dependency is possible, but
can't be encoded through the normal means of DEPS_regex because it is a
test-only dependency and it must be a *host* dependency (it's a syntax
extension).
Alex Crichton [Tue, 29 Apr 2014 15:55:40 +0000 (08:55 -0700)]
mk: Depend on regex_macros for tests appropriately
There is currently not much precedent for target crates requiring syntax
extensions to compile their test versions. This dependency is possible, but
can't be encoded through the normal means of DEPS_regex because it is a
test-only dependency and it must be a *host* dependency (it's a syntax
extension).
auto merge of #13807 : ipetkov/rust/issue-13771, r=alexcrichton
All links inside docblocks will have their color set to `#4e8bca` (a light blue color to contrast against the black text). This color also offers a visible contrast from the surrounding text if viewed as grayscale, making it suitable for accessability.
Docblock links will also be underlined when hovered over.
Before:
![screen shot 2014-04-27 at 12 47 06 pm](https://cloud.githubusercontent.com/assets/1638690/2812157/00e53a32-ce45-11e3-81e8-7b1dc692f6b7.png)
After (links underlined only on hover, cursor not shown in image):
![screen shot 2014-04-27 at 12 47 48 pm](https://cloud.githubusercontent.com/assets/1638690/2812158/04fa94b4-ce45-11e3-9ead-2344753c251d.png)
auto merge of #13829 : alexcrichton/rust/dead-strip, r=thestinger
This flag to the linker asks it to strip away all dead code during linking, as
well as dead data. This reduces the size of hello world from 1.7MB to 458K on my
system (70% reduction).
I have not seen this impact link times negatively, and I have seen this pass
'make check' successfully. I am slightly wary of adding this option, but the
benefits are so huge tha I think we should work hard to work around any issues
rather than avoid using the flag entirely.
Ivan Petkov [Sun, 27 Apr 2014 19:37:48 +0000 (12:37 -0700)]
rustdoc: #13771: Make html links inside paragraphs more readable
All links inside docblocks will have their color set to `#4e8bca` (a
light blue color to contrast against the black text). This color also
offers a visible contrast from the surrounding text if viewed as
grayscale, making it suitable for accessability.
Docblock links will also be underlined when hovered over.
auto merge of #13830 : noamraph/rust/doc-browser-history, r=kballard
Currently, in both chrome and firefox, if I type something in the search box in the reference docs I get immediately the search results. That's great. However, if I want to go back to the doc I was reading and try to press the back button, I am immediately forwarded again to the search results. This is caused by the fact that the search term is (deliberately) left in the search box, and the search() function is called as if I typed the search term again.
I disabled calling the search() function if there's no search term in the URL, and now it seems to work fine.
I hope I'm sending the pull request correctly - I'm not really used to git and github.
auto merge of #13819 : nick29581/rust/ty_str, r=pcwalton
Similar to my recent changes to ~[T]/&[T], these changes remove the vstore abstraction and represent str types as ~(str) and &(str). The Option<uint> in ty_str is the length of the string, None if the string is dynamically sized.
Alex Crichton [Mon, 28 Apr 2014 20:20:08 +0000 (13:20 -0700)]
rustc: Pass -dead_strip on OSX
This flag to the linker asks it to strip away all dead code during linking, as
well as dead data. This reduces the size of hello world from 1.7MB to 458K on my
system (70% reduction).
I have not seen this impact link times negatively, and I have seen this pass
'make check' successfully. I am slightly wary of adding this option, but the
benefits are so huge tha I think we should work hard to work around any issues
rather than avoid using the flag entirely.
auto merge of #13812 : alxgnon/rust/master, r=alexcrichton
This is a quick fix for repeated documentation descriptions in certain modules.
Following is a list of the faulty modules I found. I ran `pcregrep -r -M "<p>(.+)\n\1" doc` on the html documentation to help identify them.
After a little testing, I discovered that moving the documentation inside (`//!`) instead of outside (`///`) modules fixed the immediate problem. I went through the trouble of moving the documentation, and with this commit there are no more repeated descriptions within those faulty modules.
This does not fix the underlying problem though. We should look into why having the documentation outside instead of inside caused the descriptions to be repeated. I will create a separate issue with my findings on the subject if necessary.
In the meantime, this simple fix should be enough.
auto merge of #13797 : lifthrasiir/rust/std-mem-replace-doc, r=alexcrichton
Inspired by @steveklabnik's [comment](http://www.reddit.com/r/rust/comments/240p9s/eli5_stdmemreplace/ch2gxw8), this PR adds the practical use cases to the documentation of `std::mem::replace`.
Caveat: We need a `compile-fail` equivalent for doctest. :p
auto merge of #13791 : lifthrasiir/rust/mod-inner-span, r=huonw
This PR is primarily motivated by (and fixes) #12926.
We currently only have a span for the individual item itself and not for the referred contents. This normally does not cause a problem since both are located in the same file; it *is* possible that the contained statement or item is located in the other file (the syntax extension can do that), but even in that case the syntax extension should be located in the same file as the item. The module item (i.e. `mod foo;`) is the only exception here, and thus warrants a special treatment.
Rustdoc would now distinguish `mod foo;` from `mod foo {...}` by checking if the span for the module item and module contents is in different files. If it's the case, we'd prefer module contents over module item. There are alternative strategies, but as noted above we will have some corner cases if we don't record the contents span explicitly.
Nick Cameron [Sat, 26 Apr 2014 22:19:15 +0000 (10:19 +1200)]
Refactor ty_str to use a ~(str) representation.
Similar to my recent changes to ~[T]/&[T], these changes remove the vstore abstraction and represent str types as ~(str) and &(str). The Option<uint> in ty_str is the length of the string, None if the string is dynamically sized.
auto merge of #13799 : m-r-r/rust/patch-std-io-standard_error, r=alexcrichton
Hello,
With the latest version of Rust, calling to the function [`std::io::standard_error()`](http://static.rust-lang.org/doc/master/std/io/fn.standard_error.html) succeeds only if the value of the argument is `EndOfFile`, `IoUnavailable` or `InvalidInput`. If the function is called with another value as argument, it fails without message.
Here is a piece of code that reproduces the problem:
```rust
use std::io::{standard_error,EndOfFile,FileNotFound,PermissionDenied};
fn main() {
println!("Error 1: {}", standard_error(EndOfFile)); // does not fail
println!("Error 2: {}", standard_error(FileNotFound)); // fails
println!("Error 3: {}", standard_error(PermissionDenied)); //fails
}
```
This was because the `IoErrorKind` passed as argument wasn't matched against all the possible values.
I added the missing branches in the `match` statement inside the function, and i removed the call to the `fail!()` macro. I rebuilt the crate with the latest `rustc` version and it seems to works.
auto merge of #13792 : jacob-hegna/rust/master, r=alexcrichton
Just modified the documentation for parse_bytes to make it more clear how the bytes were parsed (big endian) and to show an example of what it returned. I also added documentation for the to_str_bytes which previously had no documentation (besides one stackoverflow post).
Kang Seonghoon [Sat, 26 Apr 2014 20:08:36 +0000 (05:08 +0900)]
rustdoc: External module item links to the module contents. Fixes #12926.
the basic strategy is to distinguish `mod foo;` from `mod foo {...}`
by checking if the span for the module item and module contents is
in different files. if it's the case, we prefer module contents.
it is technically possible to fix #12926 without changing the AST,
probably by checking the individual items' span. this is not without
a problem though, since it is possible that some items inside
`mod foo {...}` may have originated from other file (e.g. `include!`).
therefore it is better to record both spans explicitly.
auto merge of #13783 : wackywendell/rust/permfix, r=kballard
I filed bugs #13734 and #13759 recently, and then realized I could probably fix them myself. This does exactly that, with a couple additional modifications and additions to the test-suite to pick up on that.
I've never done this before, so please feel free to tell me all the things I'm doing wrong or could be doing better.
Kang Seonghoon [Sat, 26 Apr 2014 20:05:45 +0000 (05:05 +0900)]
syntax: `Mod` records the span for inner contents.
this is useful when the module item and module contents are defined
from different files (like rustdoc). in most cases the original span
for the module item would be used; in other cases, the span for
module contents is available separately at the `inner` field.
auto merge of #13777 : lifthrasiir/rust/no-multi-viewitemuse, r=alexcrichton
It reflected the obsolete syntax `use a, b, c;` and did not make past the parser (though it was a non-fatal error so we can continue). This legacy affected many portions of rustc and rustdoc as well, so this PR cleans them up altogether.
As a side effect of cleanup, we now have `SCHEMA_VERSION` in `rustdoc::clean` (instead of the crate root), so it has a better chance to be updated when `rustdoc::clean` gets updated.
Kang Seonghoon [Sat, 26 Apr 2014 13:33:45 +0000 (22:33 +0900)]
syntax: ViewItemUse no longer contains multiple view paths.
it reflected the obsolete syntax `use a, b, c;` and did not make
past the parser (though it was a non-fatal error so we can continue).
this legacy affected many portions of rustc and rustdoc as well,
so this commit cleans them up altogether.
auto merge of #13766 : BurntSushi/rust/regex-dynamic-tests, r=alexcrichton
Before, tests for dynamic regexes ran during stage1 and tests for
native regexes ran during stage2. But the buildbots don't test stage1,
so now both dynamic and native tests are run during stage2.
auto merge of #13758 : sodaplayer/rust/patch-1, r=alexcrichton
Rustdoc doesn't seem like it's converting the old format to a table as we can see here:
http://static.rust-lang.org/doc/master/complement-cheatsheet.html#ffi-(foreign-function-interface)
This new format should fix that and it's also rendered by Github's markdown preview.
auto merge of #13750 : aturon/rust/issue-12583, r=alexcrichton
Clarifies the interaction of `is_dir`, `is_file` and `exists` with
symbolic links. Adds a convenience `lstat` function alongside of
`stat`. Removes references to conditions.
auto merge of #13744 : adrientetar/rust/derp, r=brson
- Serve webfonts locally
- Style changes around `blockquote` and `code`
- Minor adjustments from previous changes
Bringing back updated examples: [modified tutorial](http://adrientetar.legtux.org/cached/rust-docs/tutorial.htm) and [modified manual](http://adrientetar.legtux.org/cached/rust-docs/manual.htm).
And for rustdoc, [modified `enum.FileType`](http://adrientetar.legtux.org/cached/rust-docs/enum.FileType.htm), [modified `std`](http://adrientetar.legtux.org/cached/rust-docs/std.htm) and [modified `std::io`](http://adrientetar.legtux.org/cached/rust-docs/io.htm).
clarify docs for std:io::fs::Path::{is_dir,is_file,exists}; add lstat
Clarifies the interaction of `is_dir`, `is_file` and `exists` with
symbolic links. Adds a convenience `lstat` function alongside of
`stat`. Removes references to conditions.
Andrew Gallant [Fri, 25 Apr 2014 21:28:05 +0000 (17:28 -0400)]
Tests for dynamic regexes will now run during 'check-stage2'.
Before, tests for dynamic regexes ran during stage1 and tests for
native regexes ran during stage2. But the buildbots don't test stage1,
so now both dynamic and native tests are run during stage2.
John Fresco [Fri, 25 Apr 2014 19:07:30 +0000 (13:07 -0600)]
Update FFI signature table to use pipe format
Rustdoc doesn't seem like it's converting the old format to a table as we can see here:
http://static.rust-lang.org/doc/master/complement-cheatsheet.html#ffi-(foreign-function-interface)
This new format should fix that and it's also rendered by Github's markdown preview.
auto merge of #13735 : aturon/rust/float-consts-take-2, r=brson
Follow-up on issue #13297 and PR #13710. Instead of following the (confusing) C/C++ approach
of using `MIN_VALUE` for the smallest *positive* number, we introduce `MIN_POS_VALUE` (and
in the Float trait, `min_pos_value`) to represent this number.
This patch also removes a few remaining redundantly-defined constants that were missed last
time around.
auto merge of #13700 : BurntSushi/rust/regexp, r=alexcrichton
Implements [RFC 7](https://github.com/rust-lang/rfcs/blob/master/active/0007-regexps.md) and will hopefully resolve #3591. The crate is marked as experimental. It includes a syntax extension for compiling regexps to native Rust code.
Embeds and passes the `basic`, `nullsubexpr` and `repetition` tests from [Glenn Fowler's (slightly modified by Russ Cox for leftmost-first semantics) testregex test suite](http://www2.research.att.com/~astopen/testregex/testregex.html). I've also hand written a plethora of other tests that exercise Unicode support, the parser, public API, etc. Also includes a `regex-dna` benchmark for the shootout.
I know the addition looks huge at first, but consider these things:
1. More than half the number of lines is dedicated to Unicode character classes.
2. Of the ~4,500 lines remaining, 1,225 of them are comments.
3. Another ~800 are tests.
4. That leaves 2500 lines for the meat. The parser is ~850 of them. The public API, compiler, dynamic VM and code generator (for `regexp!`) make up the rest.
auto merge of #13697 : pongad/rust/consts, r=alexcrichton
I decided to put architecture constants in another mod. They are not used, so a part of me is thinking of just getting rid of them altogether. The rest should be similar to what @brson wants.
Fixes #13536
auto merge of #13723 : alexcrichton/rust/pipe-connect-timeout, r=brson
This adds support for connecting to a unix socket with a timeout (a named pipe
on windows), and accepting a connection with a timeout. The goal is to bring
unix pipes/named sockets back in line with TCP support for timeouts.
Similarly to the TCP sockets, all methods are marked #[experimental] due to
uncertainty about the type of the timeout argument.
This internally involved a good bit of refactoring to share as much code as
possible between TCP servers and pipe servers, but the core implementation did
not change drastically as part of this commit.
Follow-up on issue #13297 and PR #13710. Instead of following the (confusing) C/C++ approach
of using `MIN_VALUE` for the smallest *positive* number, we introduce `MIN_POS_VALUE` (and
in the Float trait, `min_pos_value`) to represent this number.
This patch also removes a few remaining redundantly-defined constants that were missed last
time around.
Alex Crichton [Wed, 23 Apr 2014 01:38:59 +0000 (18:38 -0700)]
std: Add timeouts to unix connect/accept
This adds support for connecting to a unix socket with a timeout (a named pipe
on windows), and accepting a connection with a timeout. The goal is to bring
unix pipes/named sockets back in line with TCP support for timeouts.
Similarly to the TCP sockets, all methods are marked #[experimental] due to
uncertainty about the type of the timeout argument.
This internally involved a good bit of refactoring to share as much code as
possible between TCP servers and pipe servers, but the core implementation did
not change drastically as part of this commit.
auto merge of #13729 : chris-morgan/rust/fix-vim-indent, r=alexcrichton
The change in #13600 was incorrect, containing a bad regular expression;
inside an indent function, errors are silently ignored (and the ``~=``
operation will return 0), so it just always failed, causing the cases
that were supposed to be caught to not be caught and making things like
the ``match`` example shown above or struct field definitions regress.
I have fixed the regular expression to what it should have been. This is
still imperfect, of course, not handling cases like where the first
argument to a function is a function call (``foo(bar(),``), but it'll do
for now.
----
I have a general request to make of reviewers about any changes made to `src/etc/vim`: **please tell me**. As a general rule I want to review them. (I’ll make an exception for changes the prelude; it needs fixing from time to time when some people don’t update the syntax file, anyway.)
auto merge of #13720 : aturon/rust/walk_dir-perf, r=alexcrichton
The `walk_dir` iterator was simulating a queue using a vector (in particular, using `shift`),
leading to O(n^2) performance. Since the order was not well-specified (see issue #13411),
the simplest fix is to use the vector as a stack (and thus yield a depth-first traversal).
This patch does exactly that, and adds a test checking for depth-first behavior.
Note that the underlying `readdir` function does not specify any particular order, nor
does the system call it uses.
auto merge of #13706 : alexcrichton/rust/test-nocapture, r=brson
A new flag to the test runner, --nocapture, can be passed to instruct that the
output of tests should not be captured by default. The behavior can also be
triggered via a RUST_TEST_NOCAPTURE environment variable being set.
The `walk_dir` iterator was simulating a queue using a vector (in particular, using `shift`),
leading to O(n^2) performance. Since the order was not well-specified (see issue #13411),
the simplest fix is to use the vector as a stack (and thus yield a depth-first traversal).
This patch does exactly that. It leaves the order as originally specified -- "some top-down
order" -- and adds a test to ensure a top-down traversal.
Note that the underlying `readdir` function does not specify any particular order, nor
does the system call it uses.
auto merge of #13619 : alexcrichton/rust/update-libuv, r=brson
This update brings a few months of changes, but primarily a fix for the
following situation.
When creating a handle to stdin, libuv used to set the stdin handle to
nonblocking mode. This would end up affect this stdin handle across all
processes that shared it, which mean that stdin become nonblocking for everyone
using the same stdin. On linux, this also affected *stdout* because stdin/stdout
roughly point at the same thing.
This problem became apparent when running the test suite manually on a local
computer. The stdtest suite (running with libgreen) would set stdout to
nonblocking mode (as described above), and then the next test suite would always
fail for a printing failure (because stdout was returning EAGAIN).
This has been fixed upstream, joyent/libuv@342e8c, and this update pulls in this
fix. This also brings us in line with a recently upstreamed libuv patch.
Alex Crichton [Wed, 23 Apr 2014 16:38:46 +0000 (09:38 -0700)]
test: Add an option to not capture output
A new flag to the test runner, --nocapture, can be passed to instruct that the
output of tests should not be captured by default. The behavior can also be
triggered via a RUST_TEST_NOCAPTURE environment variable being set.
Alex Crichton [Sat, 19 Apr 2014 02:09:31 +0000 (19:09 -0700)]
Update libuv
This update brings a few months of changes, but primarily a fix for the
following situation.
When creating a handle to stdin, libuv used to set the stdin handle to
nonblocking mode. This would end up affect this stdin handle across all
processes that shared it, which mean that stdin become nonblocking for everyone
using the same stdin. On linux, this also affected *stdout* because stdin/stdout
roughly point at the same thing.
This problem became apparent when running the test suite manually on a local
computer. The stdtest suite (running with libgreen) would set stdout to
nonblocking mode (as described above), and then the next test suite would always
fail for a printing failure (because stdout was returning EAGAIN).
This has been fixed upstream, joyent/libuv@342e8c, and this update pulls in this
fix. This also brings us in line with a recently upstreamed libuv patch.
auto merge of #13713 : edwardw/rust/methodcall-span, r=alexcrichton
Specifically, the method parameter cardinality mismatch or missing
method error message span now gets method itself exactly. It was the
whole expression.
Chris Morgan [Thu, 24 Apr 2014 13:33:28 +0000 (23:33 +1000)]
Fix Vim indent regressions from #13600.
The change in #13600 was incorrect, containing a bad regular expression;
inside an indent function, errors are silently ignored (and the ``~=``
operation will return 0), so it just always failed, causing the cases
that were supposed to be caught to not be caught and making things like
the ``match`` example shown above or struct field definitions regress.
I have fixed the regular expression to what it should have been. This is
still imperfect, of course, not handling cases like where the first
argument to a function is a function call (``foo(bar(),``), but it'll do
for now.
auto merge of #13559 : FlaPer87/rust/remove-special-root, r=nikomatsakis
This patch removes the special auto-rooting for `@` from the borrow checker. With `@` moving into a library, it doesn't make sense to keep this code around anymore. It also simplifies `trans` by removing root checking from there
auto merge of #13710 : aturon/rust/float-constants, r=brson
Some of the constant values in std::f32 were incorrectly copied from
std::f64. More broadly, both modules defined their constants redundantly
in two places, which is what led to the bug. Moreover, the specs for
some of the constants were incorrect, even when the values were correct.
auto merge of #13688 : alexcrichton/rust/accept-timeout, r=brson
This adds experimental support for timeouts when accepting sockets through
`TcpAcceptor::accept`. This does not add a separate `accept_timeout` function,
but rather it adds a `set_timeout` function instead. This second function is
intended to be used as a hard deadline after which all accepts will never block
and fail immediately.
This idea was derived from Go's SetDeadline() methods. We do not currently have
a robust time abstraction in the standard library, so I opted to have the
argument be a relative time in millseconds into the future. I believe a more
appropriate argument type is an absolute time, but this concept does not exist
yet (this is also why the function is marked #[experimental]).
The native support is built on select(), similarly to connect_timeout(), and the
green support is based on channel select and a timer.
Alex Crichton [Tue, 22 Apr 2014 03:30:07 +0000 (20:30 -0700)]
std: Add support for an accept() timeout
This adds experimental support for timeouts when accepting sockets through
`TcpAcceptor::accept`. This does not add a separate `accept_timeout` function,
but rather it adds a `set_timeout` function instead. This second function is
intended to be used as a hard deadline after which all accepts will never block
and fail immediately.
This idea was derived from Go's SetDeadline() methods. We do not currently have
a robust time abstraction in the standard library, so I opted to have the
argument be a relative time in millseconds into the future. I believe a more
appropriate argument type is an absolute time, but this concept does not exist
yet (this is also why the function is marked #[experimental]).
The native support is built on select(), similarly to connect_timeout(), and the
green support is based on channel select and a timer.