bors [Sun, 29 Mar 2015 19:47:18 +0000 (19:47 +0000)]
Auto merge of #23820 - sfackler:fast_read_to_end, r=alexcrichton
with_end_to_cap is enormously expensive now that it's initializing
memory since it involves 64k allocation + memset on every call. This is
most noticable when calling read_to_end on very small readers, where the
new version if **4 orders of magnitude** faster.
BufReader also depended on with_end_to_cap so I've rewritten it in its
original form.
As a bonus, converted the buffered IO struct Debug impls to use the
debug builders.
I first came across this in sfackler/rust-postgres#106 where a user reported a 10x performance regression. A call to read_to_end turned out to be the culprit: https://github.com/sfackler/rust-postgres/commit/9cd413d42c287154d6c64cc7913666b0517f35f3.
The new version differs from the old in a couple of ways. The buffer size used is now adaptive. It starts at 32 bytes and doubles each time EOF hasn't been reached up to a limit of 64k. In addition, the buffer is only truncated when EOF or an error has been reached, rather than after every call to read as was the case for the old implementation.
I wrote up a benchmark to compare the old version and new version: https://gist.github.com/sfackler/e979711b0ee2f2063462
It tests a couple of different cases: a high bandwidth reader, a low bandwidth reader, and a low bandwidth reader that won't return more than 10k per call to `read`. The high bandwidth reader should be analagous to use cases when reading from e.g. a `BufReader` or `Vec`, and the low bandwidth readers should be analogous to reading from something like a `TcpStream`.
Of special note, reads from a high bandwith reader containing 4 bytes are now *4,495 times faster*.
```
~/foo ❯ cargo bench
Compiling foo v0.0.1 (file:///home/sfackler/foo)
Running target/release/foo-7498d7dd7faecf5c
running 13 tests
test test_new ... ignored
test new_delay_4 ... bench: 230768 ns/iter (+/- 14812)
test new_delay_4_cap ... bench: 231421 ns/iter (+/- 7211)
test new_delay_5m ... bench: 14495370 ns/iter (+/- 4008648)
test new_delay_5m_cap ... bench: 73127954 ns/iter (+/- 59908587)
test new_nodelay_4 ... bench: 83 ns/iter (+/- 2)
test new_nodelay_5m ... bench: 12527237 ns/iter (+/- 335243)
test std_delay_4 ... bench: 373095 ns/iter (+/- 12613)
test std_delay_4_cap ... bench: 374190 ns/iter (+/- 19611)
test std_delay_5m ... bench: 17356012 ns/iter (+/- 15906588)
test std_delay_5m_cap ... bench: 883555035 ns/iter (+/- 205559857)
test std_nodelay_4 ... bench: 144937 ns/iter (+/- 2448)
test std_nodelay_5m ... bench: 16095893 ns/iter (+/- 3315116)
test result: ok. 0 passed; 0 failed; 1 ignored; 12 measured
```
bors [Sun, 29 Mar 2015 11:12:26 +0000 (11:12 +0000)]
Auto merge of #23809 - cmr:issue-21310, r=Manishearth
This isn't really possible to test in an automatic way, since the only traits
you can negative impl are `Send` and `Sync`, and the implementors page for
those only exists in libstd.
bors [Sun, 29 Mar 2015 08:14:30 +0000 (08:14 +0000)]
Auto merge of #23787 - steveklabnik:gh23760, r=alexcrichton
This was originally used to set up the guessing game, but that no longer
exists. This version uses `old_io`, and updating it involves talking
about `&mut` and such, which we haven't covered yet. So, for now, let's
just remove it.
Steven Fackler [Sun, 29 Mar 2015 01:47:29 +0000 (18:47 -0700)]
Fix massive performance issue in read_to_end
with_end_to_cap is enormously expensive now that it's initializing
memory since it involves 64k allocation + memset on every call. This is
most noticable when calling read_to_end on very small readers, where the
new version if **4 orders of magnitude** faster.
BufReader also depended on with_end_to_cap so I've rewritten it in its
original form.
As a bonus, converted the buffered IO struct Debug impls to use the
debug builders.
bors [Sun, 29 Mar 2015 05:21:29 +0000 (05:21 +0000)]
Auto merge of #23810 - sfackler:debug-collections, r=alexcrichton
The collections debug helpers no longer prefix output with the
collection name, in line with the current conventions for Debug
implementations. Implementations that want to preserve the current
behavior can simply add a `try!(write!(fmt, "TypeName "));` at the
beginning of the `fmt` method.
bors [Sun, 29 Mar 2015 02:33:27 +0000 (02:33 +0000)]
Auto merge of #23819 - pnkfelix:kill-unsafe-dtor, r=pnkfelix
Port of pcwalton removal of `#[unsafe_destructor]` check.
Earlier commits impose rules on lifetimes that make generic destructors safe; thus we no longer need the `#[unsafe_destructor]` attribute nor its associated check.
----
So remove the check for the unsafe_destructor attribute.
And remove outdated compile-fail tests from when lifetime-parameteric dtors were disallowed/unsafe.
In addition, when one uses the attribute without the associated feature, report that the attribute is deprecated.
However, I do not think this is a breaking-change, because the attribute and feature are still currently accepted by the compiler. (After the next snapshot that has this commit, we can remove the feature itself and the attribute as well.)
----
I consider this to:
Fix #22196
(technically there is still the post snapshot work of removing the last remnants of the feature and the attribute, but the ticket can still be closed in my opinion).
Port of pcwalton removal of `#[unsafe_destructor]` check.
Earlier commits impose rules on lifetimes that make generic
destructors safe; thus we no longer need the `#[unsafe_destructor]`
attribute nor its associated check.
----
So remove the check for the unsafe_destructor attribute.
And remove outdated compile-fail tests from when lifetime-parameteric
dtors were disallowed/unsafe.
In addition, when one uses the attribute without the associated
feature, report that the attribute is deprecated.
However, I do not think this is a breaking-change, because the
attribute and feature are still currently accepted by the compiler.
(After the next snapshot that has this commit, we can remove the
feature itself and the attribute as well.)
----
I consider this to:
Fix #22196
(techincally there is still the post snapshot work of removing the
last remants of the feature and the attribute, but the ticket can
still be closed in my opinion).
Steve Klabnik [Fri, 27 Mar 2015 18:31:26 +0000 (14:31 -0400)]
Remove standard io chapter from the book
This was originally used to set up the guessing game, but that no longer
exists. This version uses `old_io`, and updating it involves talking
about `&mut` and such, which we haven't covered yet. So, for now, let's
just remove it.
Steven Fackler [Fri, 27 Mar 2015 05:42:29 +0000 (22:42 -0700)]
Update debug helpers and add list builder
The collections debug helpers no longer prefix output with the
collection name, in line with the current conventions for Debug
implementations. Implementations that want to preserve the current
behavior can simply add a `try!(write!(fmt, "TypeName "));` at the
beginning of the `fmt` method.
bors [Sat, 28 Mar 2015 05:43:12 +0000 (05:43 +0000)]
Auto merge of #23798 - alexcrichton:issue-23781, r=aturon
Previously a panic was generated for recursive prints due to a double-borrow of
a `RefCell`. This was solved by the second borrow's output being directed
towards the global stdout instead of the per-thread stdout (still experimental
functionality).
After this functionality was altered, however, recursive prints still deadlocked
due to the overridden `write_fmt` method which locked itself first and then
wrote all the data. This was fixed by removing the override of the `write_fmt`
method. This means that unlocked usage of `write!` on a `Stdout`/`Stderr` may be
slower due to acquiring more locks, but it's easy to make more performant with a
call to `.lock()`.
Alex Crichton [Fri, 27 Mar 2015 23:25:49 +0000 (16:25 -0700)]
std: Don't deadlock/panic on recursive prints
Previously a panic was generated for recursive prints due to a double-borrow of
a `RefCell`. This was solved by the second borrow's output being directed
towards the global stdout instead of the per-thread stdout (still experimental
functionality).
After this functionality was altered, however, recursive prints still deadlocked
due to the overridden `write_fmt` method which locked itself first and then
wrote all the data. This was fixed by removing the override of the `write_fmt`
method. This means that unlocked usage of `write!` on a `Stdout`/`Stderr` may be
slower due to acquiring more locks, but it's easy to make more performant with a
call to `.lock()`.
Corey Richardson [Fri, 27 Mar 2015 21:29:07 +0000 (17:29 -0400)]
rustdoc: show negative impls properly in the implementors page
This isn't really possible to test in an automatic way, since the only traits
you can negative impl are `Send` and `Sync`, and the implementors page for
those only exists in libstd.
Alex Crichton [Fri, 27 Mar 2015 20:04:27 +0000 (13:04 -0700)]
rollup merge of #23197: aatxe/master
`std::dynamic_library` is currently using `std::old_io::Path` specifically. This change brings the API in alignment with `std::fs::File` by having it take `std::path::AsPath`. The Windows code should work, but I admittedly haven't tried it (I don't have a Windows machine readily available right now).
Alex Crichton [Fri, 27 Mar 2015 19:44:00 +0000 (12:44 -0700)]
rollup merge of #23486: nikomatsakis/issue-23485
When testing whether a default method predicates are satisfiable,
combine normalization with this check so that we also skip the
default method if normalization fails. Fixes #23485.
r? @nrc (I tried to address your nit from before as well)
Niko Matsakis [Wed, 18 Mar 2015 19:26:38 +0000 (15:26 -0400)]
When testing whether a default method predicates are satisfiable,
combine normalization with this check so that we also skip the
default method if normalization fails. Fixes #23485.
Alex Crichton [Fri, 27 Mar 2015 00:35:13 +0000 (17:35 -0700)]
rustc: Remove support for hyphens in crate names
This commit removes parser support for `extern crate "foo" as bar` as the
renamed crate is now required to be an identifier. Additionally this commit
enables hard errors on crate names that contain hyphens in them, they must now
solely contain alphanumeric characters or underscores.
If the crate name is inferred from the file name, however, the file name
`foo-bar.rs` will have the crate name inferred as `foo_bar`. If a binary is
being emitted it will have the name `foo-bar` and a library will have the name
`libfoo_bar.rlib`.
This commit is a breaking change for a number of reasons:
* Old syntax is being removed. This was previously only issuing warnings.
* The output for the compiler when input is received on stdin is now `rust_out`
instead of `rust-out`.
* The crate name for a crate in the file `foo-bar.rs` is now `foo_bar` which can
affect infrastructure such as logging.
Alex Crichton [Fri, 27 Mar 2015 17:07:54 +0000 (10:07 -0700)]
rollup merge of #23780: ruud-v-a/wrapping
This allows `Wrapping<T>` to be used in `assert_eq!`, for example.
One of the tests (compile-fail/xc-private-method.rs) fails, but I can hardly imagine it is related to this change. I would also like to add a tests to ensure that `assert_eq!` compiles and keeps working in the future for `Wrapped<T>` values, but there appear to be no tests in libcore. What would be a good place to add such a test?
Alex Crichton [Fri, 27 Mar 2015 17:07:53 +0000 (10:07 -0700)]
rollup merge of #23775: alexcrichton/fix-flaky-test
Windows gets quite unhappy when a thread fails while the main thread is exiting,
frequently leading to process deadlock. This has been causing quite a few
deadlocks on the windows bots recently. The child threads are presumably failing
because the `println!` is failing due to the main thread being shut down.
Alex Crichton [Fri, 27 Mar 2015 17:07:51 +0000 (10:07 -0700)]
rollup merge of #23769: alexcrichton/stabilize-split
Now that `<[_]>::split` is an inherent method, it will trump `BufRead::split`
when `BufRead` is in scope, so there is no longer a conflict. As a result,
calling `slice.split()` will probably always give you precisely what you want!
Alex Crichton [Fri, 27 Mar 2015 17:07:49 +0000 (10:07 -0700)]
rollup merge of #23753: aturon/revise-convert
This commit revises `path` and `os_str` to use blanket impls for `From`
on reference types. This both cuts down on the number of required impls,
and means that you can pass through e.g. `T: AsRef<OsStr>` to
`PathBuf::from` without an intermediate call to `as_ref`.
It also makes a FIXME note for later generalizing the blanket impls for
`AsRef` and `AsMut` to use `Deref`/`DerefMut`, once it is possible to do
so.
Alex Crichton [Fri, 27 Mar 2015 17:07:48 +0000 (10:07 -0700)]
rollup merge of #23752: alexcrichton/remove-should-fail
This attribute has been deprecated in favor of #[should_panic]. This also
updates rustdoc to no longer accept the `should_fail` directive and instead
renames it to `should_panic`.
Alex Crichton [Fri, 27 Mar 2015 17:07:47 +0000 (10:07 -0700)]
rollup merge of #23745: oneeman/trpl-looping
Was reading the 'Looping' section of the book and was puzzled why the last example uses `0u32..10` when the others don't. Tried it out without and it seems to work, so I figured it should just be `0..10`. If there is a reason it needs to be `0u32..10` it should be explained in the text (I'd offer to do it but I have no idea).
Alex Crichton [Fri, 27 Mar 2015 17:07:45 +0000 (10:07 -0700)]
rollup merge of #23736: gmjosack/master
Found a few 404s that seemed like simple fixes:
In footer.inc, certain 404 pages were 404ing on the request to jquery.js and playpen.js. This is easily demonstrated by visiting http://doc.rust-lang.org/foo then http://doc.rust-lang.org/foo/bar. The latter 404s, looking for foo/jquery.js.
The Result docs use old_io Writer as an example. Fix the link to old_io Writer. There's probably an effort to update the example away from a deprecated api but this was a simple fix.
rustc/plugin was pointing at the old guide and it was a broken link anyways (plugin vs plugins). Point at the book instead.
Alex Crichton [Fri, 27 Mar 2015 17:07:43 +0000 (10:07 -0700)]
rollup merge of #23712: nikomatsakis/reflect-trait
This PR introduces a `Reflect` marker trait which is a supertrait of `Any`. The idea is that `Reflect` is defined for all concrete types, but is not defined for type parameters unless there is a `T:Reflect` bound. This is intended to preserve the parametricity property. This allows the `Any` interface to be stabilized without committing us to unbounded reflection that is not easily detectable by the caller.
The implementation of `Reflect` relies on an experimental variant of OIBIT. This variant behaves differently for objects, since it requires that all types exposed as part of the object's *interface* are `Reflect`, but isn't concerned about other types that may be closed over. In other words, you don't have to write `Foo+Reflect` in order for `Foo: Reflect` to hold (where `Foo` is a trait).
Given that `Any` is slated to stabilization and hence that we are committed to some form of reflection, the goal of this PR is to leave our options open with respect to parametricity. I see the options for full stabilization as follows (I think an RFC would be an appropriate way to confirm whichever of these three routes we take):
1. We make `Reflect` a lang-item.
2. We stabilize some version of the OIBIT variation I implemented as a general mechanism that may be appropriate for other use cases.
3. We give up on preserving parametricity here and just have `impl<T> Reflect for T` instead. In that case, `Reflect` is a harmless but not especially useful trait going forward.
cc @aturon
cc @alexcrichton
cc @glaebhoerl (this is more-or-less your proposal, as I understood it)
cc @reem (this is more-or-less what we discussed on IRC at some point)
cc @FlaPer87 (vaguely pertains to OIBIT)
projects / rust.git / log