bors [Mon, 23 Jun 2014 00:11:39 +0000 (00:11 +0000)]
auto merge of #15068 : erickt/rust/mem-inline, r=pcwalton
This is a couple micro-optimizations I've been sitting on for a while. This inlines a couple functions that are important to the `std::io::mem`. Ultimately, this results in about a 15% performance increase in some micro-benchmarks for my [libserialize](https://github.com/erickt/rust-serde) rewrite.
Benjamin Herr [Sun, 22 Jun 2014 17:53:56 +0000 (19:53 +0200)]
libsyntax: don't allow enum structs with no fields
Unit-like structs are written as `struct Foo;`, but we erroneously
accepted `struct Foo();` and took it to mean the same thing. Now we
don't, so use the `struct Foo;` form!
bors [Sun, 22 Jun 2014 00:01:34 +0000 (00:01 +0000)]
auto merge of #15005 : dotdash/rust/i1_bool, r=alexcrichton
We currently compiled bools to i8 values, because there was a bug in
LLVM that sometimes caused miscompilations when using i1 in, for
example, structs.
Using i8 means a lot of unnecessary zero-extend and truncate operations
though, since we have to convert the value from and to i1 when using for
example icmp or br instructions. Besides the unnecessary overhead caused
by this, it also sometimes made LLVM miss some optimizations.
First, we have to fix some bugs concerning the handling of
attributes in foreign function declarations and calls. These
are required because the i1 type needs the ZExt attribute when
used as a function parameter or return type.
Then we have to update LLVM to get a bugfix without which LLVM
sometimes generates broken code when using i1.
And then, finally, we can switch bools over to i1.
Erick Tryzelaar [Sat, 21 Jun 2014 03:05:42 +0000 (23:05 -0400)]
std: inline many of the Writer/Reader methods
This allows llvm to optimize away much of the overhead from using
the MemReader/MemWriters. My benchmarks showed it to shave 15% off
of my in progress serialization/json encoding.
Erick Tryzelaar [Tue, 3 Jun 2014 04:56:29 +0000 (21:56 -0700)]
std: micro-optimize Vec constructors and add benchmarks
Generally speaking, inlining doesn't really help out with
constructing vectors, except for when we construct a zero-sized
vector. This patch allows llvm to optimize this case away in
a lot of cases, which shaves off 4-8ns. It's not much, but it
might help in some inner loop somewhere.
before:
running 12 tests
test bench_extend_0 ... bench: 123 ns/iter (+/- 6)
test bench_extend_5 ... bench: 323 ns/iter (+/- 11)
test bench_from_fn_0 ... bench: 7 ns/iter (+/- 0)
test bench_from_fn_5 ... bench: 49 ns/iter (+/- 6)
test bench_from_iter_0 ... bench: 11 ns/iter (+/- 0)
test bench_from_iter_5 ... bench: 176 ns/iter (+/- 11)
test bench_from_slice_0 ... bench: 8 ns/iter (+/- 1)
test bench_from_slice_5 ... bench: 73 ns/iter (+/- 5)
test bench_new ... bench: 0 ns/iter (+/- 0)
test bench_with_capacity_0 ... bench: 6 ns/iter (+/- 1)
test bench_with_capacity_100 ... bench: 41 ns/iter (+/- 3)
test bench_with_capacity_5 ... bench: 40 ns/iter (+/- 2)
after:
test bench_extend_0 ... bench: 123 ns/iter (+/- 7)
test bench_extend_5 ... bench: 339 ns/iter (+/- 27)
test bench_from_fn_0 ... bench: 7 ns/iter (+/- 0)
test bench_from_fn_5 ... bench: 54 ns/iter (+/- 4)
test bench_from_iter_0 ... bench: 11 ns/iter (+/- 1)
test bench_from_iter_5 ... bench: 182 ns/iter (+/- 16)
test bench_from_slice_0 ... bench: 4 ns/iter (+/- 0)
test bench_from_slice_5 ... bench: 62 ns/iter (+/- 3)
test bench_new ... bench: 0 ns/iter (+/- 0)
test bench_with_capacity_0 ... bench: 0 ns/iter (+/- 0)
test bench_with_capacity_100 ... bench: 41 ns/iter (+/- 1)
test bench_with_capacity_5 ... bench: 41 ns/iter (+/- 3)
Björn Steinbrink [Sun, 16 Mar 2014 08:29:05 +0000 (09:29 +0100)]
Compile bools to i1
We currently compiled bools to i8 values, because there was a bug in
LLVM that sometimes caused miscompilations when using i1 in, for
example, structs.
Using i8 means a lot of unnecessary zero-extend and truncate operations
though, since we have to convert the value from and to i1 when using for
example icmp or br instructions. Besides the unnecessary overhead caused
by this, it also sometimes made LLVM miss some optimizations.
Björn Steinbrink [Tue, 17 Jun 2014 16:34:50 +0000 (18:34 +0200)]
Update LLVM
To fix #8106, we need an LLVM version that contains r211082 aka 0dee6756
which fixes a bug that blocks that issue.
There have been some tiny API changes in LLVM, and cmpxchg changed its
return type. The i1 part of the new return type is only interesting when
using the new weak cmpxchg, which we don't do.
Björn Steinbrink [Tue, 17 Jun 2014 19:51:24 +0000 (21:51 +0200)]
Add missing attributes to indirect calls for foreign functions
When calling a foreign function, some arguments and/or return value
attributes are required to conform to the foreign ABI. Currently those
attributes are only added to the declaration of foreign functions. With
direct calls, this is no problem, because LLVM can see that those
attributes apply to the call. But with an indirect call, LLVM cannot do
that and the attribute is missing.
To fix that, we have to add those attribute to the calls to foreign
functions as well.
This also allows to remove the special handling of the SRet attribute,
which is ABI-dependent and will be set via the `attr` field of the
return type's `ArgType`.
Björn Steinbrink [Wed, 18 Jun 2014 11:01:23 +0000 (13:01 +0200)]
Correctly set return type attributes on foreign function declarations
The ArgType type gives us a generic way to specify an attribute for a
type to ensure ABI conformance for foreign functions. But the code that
actually sets the argument attributes in the function declaration
only sets the attribute for the return type when the type is indirect.
Since LLVMAddAttribute() doesn't allow to set attributes on the return
type, we have to use LLVMAddFunctionAttribute() instead.
This didn't cause problems yet, because currently only some indirect
types require attributes to be set.
bors [Sat, 21 Jun 2014 04:01:25 +0000 (04:01 +0000)]
auto merge of #15029 : aturon/rust/stability-index, r=brson
This commit makes several changes to the stability index infrastructure:
* Stability levels are now inherited lexically, i.e., each item's
stability level becomes the default for any nested items.
* The computed stability level for an item is stored as part of the
metadata. When using an item from an external crate, this data is
looked up and cached.
* The stability lint works from the computed stability level, rather
than manual stability attribute annotations. However, the lint still
checks only a limited set of item uses (e.g., it does not check every
component of a path on import). This will be addressed in a later PR,
as part of issue #8962.
* The stability lint only applies to items originating from external
crates, since the stability index is intended as a promise to
downstream crates.
* The "experimental" lint is now _allow_ by default. This is because
almost all existing crates have been marked "experimental", pending
library stabilization. With inheritance in place, this would generate
a massive explosion of warnings for every Rust program.
The lint should be changed back to deny-by-default after library
stabilization is complete.
* The "deprecated" lint still warns by default.
The net result: we can begin tracking stability index for the standard
libraries as we stabilize, without impacting most clients.
bors [Sat, 21 Jun 2014 02:11:22 +0000 (02:11 +0000)]
auto merge of #14731 : jakub-/rust/pattern-matching-refactor, r=alexcrichton
This PR is changing the error messages for non-exhaustive pattern matching to include a more accurate witness, i.e. a pattern that is not covered by any of the ones provided by the user. Example:
bors [Fri, 20 Jun 2014 21:31:22 +0000 (21:31 +0000)]
auto merge of #14988 : pcwalton/rust/unsafe-destructor-feature-gate, r=alexcrichton
Closes #8142.
This is not the semantics we want long-term. You can continue to use
`#[unsafe_destructor]`, but you'll need to add
`#![feature(unsafe_destructor)]` to the crate attributes.
Patrick Walton [Tue, 17 Jun 2014 23:00:04 +0000 (16:00 -0700)]
librustc: Put `#[unsafe_destructor]` behind a feature gate.
Closes #8142.
This is not the semantics we want long-term. You can continue to use
`#[unsafe_destructor]`, but you'll need to add
`#![feature(unsafe_destructor)]` to the crate attributes.
bors [Fri, 20 Jun 2014 17:06:19 +0000 (17:06 +0000)]
auto merge of #15056 : alexcrichton/rust/issue-15043, r=kballard
The parser already has special logic for parsing `>` tokens from `>>`, and this
commit extends the logic to the acquiring a `>` from the `>=` and `>>=` tokens
as well.
Alex Crichton [Fri, 20 Jun 2014 16:53:12 +0000 (09:53 -0700)]
syntax: Parse GT tokens from `>=` and `>>=`
The parser already has special logic for parsing `>` tokens from `>>`, and this
commit extends the logic to the acquiring a `>` from the `>=` and `>>=` tokens
as well.
Alexandre Gagnon [Fri, 20 Jun 2014 03:17:49 +0000 (23:17 -0400)]
std::sync::TaskPool: Improve module documentation
The struct and module doc comments are reformulated. The `execute`
method's documentation are put up to date, and failure information
is added. A test is also added to address the possible failure.
Huon Wilson [Thu, 19 Jun 2014 13:16:14 +0000 (23:16 +1000)]
testing guide: update to use `test_harness` & fix problems.
rustdoc now supports compiling things with `--test` so the examples in
this guide can be compiled & tested properly (revealing a few issues &
out-dated behaviours).
bors [Thu, 19 Jun 2014 19:21:26 +0000 (19:21 +0000)]
auto merge of #15037 : zzmp/rust/doc/hotkeys, r=alexcrichton
Continuing from #15012, this makes four changes to the `rustdoc` static files.
- Change the placeholder text of the search bar to `Click or press 'S' to search, '?' for more options...` to make keyboard hotkeys more apparent (capitalizing the `S` to match the help text).
- Change the `main.js` file to use browser-normalized key codes (`e.which`, from `jQuery`), instead of `e.keyCode`.
- Change the key code for `?` to be the correct `191` instead of `188`, so that the hotkey works to bring up search information.
- Change the search information to display `tab` and `shift+tab` instead of `up` and `down`, as those do not yet work outside of Firefox (see #15011). Also, adjust the height so it does not cut off the help text.
<s>I've also opened up #15038 about the non-functional `up` and `down` functionality, although this does nothing to fix it.</s>
bors [Thu, 19 Jun 2014 17:26:26 +0000 (17:26 +0000)]
auto merge of #15033 : Sawyer47/rust/old-test, r=alexcrichton
This test was added long time ago and marked as ignored.
The same test was added later in #8485 as run-fail/issue-3907.rs,
but the old one was not deleted.
Zach Pomerantz [Wed, 18 Jun 2014 18:25:04 +0000 (11:25 -0700)]
(doc) Properly doc hotkeys in generated docs.
Updated search bar to match help text.
Used correct, normalized hotkeys in search.
Updated shortcut menu with working shortcuts (tabs).
Changed height of search help.
Huon Wilson [Thu, 19 Jun 2014 13:11:18 +0000 (23:11 +1000)]
rustdoc: add the ability to run tests with --test.
This adds the `test_harness` directive that runs a code block using the
test runner, to allow for `#[test]` items to be demonstrated and still
tested (currently they are just stripped and not even compiled, let
alone run).
Aaron Turon [Thu, 12 Jun 2014 00:23:11 +0000 (17:23 -0700)]
Add stability inheritance
This commit makes several changes to the stability index infrastructure:
* Stability levels are now inherited lexically, i.e., each item's
stability level becomes the default for any nested items.
* The computed stability level for an item is stored as part of the
metadata. When using an item from an external crate, this data is
looked up and cached.
* The stability lint works from the computed stability level, rather
than manual stability attribute annotations. However, the lint still
checks only a limited set of item uses (e.g., it does not check every
component of a path on import). This will be addressed in a later PR,
as part of issue #8962.
* The stability lint only applies to items originating from external
crates, since the stability index is intended as a promise to
downstream crates.
* The "experimental" lint is now _allow_ by default. This is because
almost all existing crates have been marked "experimental", pending
library stabilization. With inheritance in place, this would generate
a massive explosion of warnings for every Rust program.
The lint should be changed back to deny-by-default after library
stabilization is complete.
* The "deprecated" lint still warns by default.
The net result: we can begin tracking stability index for the standard
libraries as we stabilize, without impacting most clients.
bors [Thu, 19 Jun 2014 05:21:16 +0000 (05:21 +0000)]
auto merge of #14400 : kballard/rust/lexer_crlf_handling, r=cmr
The lexer already ignores CRLF in between tokens, but it doesn't
properly handle carriage returns inside strings and doc comments. Teach
it to treat CRLF as LF inside these tokens, and to disallow carriage
returns that are not followed by linefeeds. This includes handling an
escaped CRLF inside a regular string token the same way it handles an
escaped LF.
This is technically a breaking change, as bare carriage returns are no
longer allowed, and CRLF sequences are now treated as LF inside strings
and doc comments, but it's very unlikely to actually affect any
real-world code.
This change is necessary to have Rust code compile on Windows the same
way it does on Unix. The mozilla/rust repository explicitly sets eol=lf
for Rust source files, but other Rust repositories don't. Notably,
rust-http cannot be compiled on Windows without converting the CRLF line
endings back to LF.
Kevin Ballard [Sat, 24 May 2014 08:13:59 +0000 (01:13 -0700)]
Handle CRLF properly in the lexer
The lexer already ignores CRLF in between tokens, but it doesn't
properly handle carriage returns inside strings and doc comments. Teach
it to treat CRLF as LF inside these tokens, and to disallow carriage
returns that are not followed by linefeeds. This includes handling an
escaped CRLF inside a regular string token the same way it handles an
escaped LF.
This is technically a breaking change, as bare carriage returns are no
longer allowed, and CRLF sequences are now treated as LF inside strings
and doc comments, but it's very unlikely to actually affect any
real-world code.
This change is necessary to have Rust code compile on Windows the same
way it does on Unix. The mozilla/rust repository explicitly sets eol=lf
for Rust source files, but other Rust repositories don't. Notably,
rust-http cannot be compiled on Windows without converting the CRLF line
endings back to LF.
bors [Thu, 19 Jun 2014 03:31:18 +0000 (03:31 +0000)]
auto merge of #15014 : brson/rust/all-crates-experimental, r=cmr
This creates a stability baseline for all crates that we distribute that are not `std`. In general, all library code must start as experimental and progress in stages to become stable.
Simon Sapin [Wed, 18 Jun 2014 18:25:36 +0000 (20:25 +0200)]
Deprecate the bytes!() macro.
Replace its usage with byte string literals, except in `bytes!()` tests.
Also add a new snapshot, to be able to use the new b"foo" syntax.
The src/etc/2014-06-rewrite-bytes-macros.py script automatically
rewrites `bytes!()` invocations into byte string literals.
Pass it filenames as arguments to generate a diff that you can inspect,
or `--apply` followed by filenames to apply the changes in place.
Diffs can be piped into `tip` or `pygmentize -l diff` for coloring.
Edward Wang [Wed, 18 Jun 2014 14:33:58 +0000 (22:33 +0800)]
Fix #14865
Fixes a codegen bug which generates illegal non-terminated LLVM block
when there are wildcard pattern with guard and enum patterns in a match
expression. Also refactors the code a little.
Aaron Turon [Tue, 17 Jun 2014 21:48:54 +0000 (14:48 -0700)]
Revamp TaskBuilder API
This patch consolidates and cleans up the task spawning APIs:
* Removes the problematic `future_result` method from `std::task::TaskBuilder`,
and adds a `try_future` that both spawns the task and returns a future
representing its eventual result (or failure).
* Removes the public `opts` field from `TaskBuilder`, instead adding appropriate
builder methods to configure the task.
* Adds extension traits to libgreen and libnative that add methods to
`TaskBuilder` for spawning the task as a green or native thread.
Previously, there was no way to benefit from the `TaskBuilder` functionality and
also set the scheduler to spawn within.
With this change, all task spawning scenarios are supported through the
`TaskBuilder` interface.
Kevin Ballard [Tue, 27 May 2014 22:00:22 +0000 (15:00 -0700)]
vim: Add :Run and :Expand commands
Define a command :Run to compile and run the current file. This supports
unnamed buffers (by writing to a temporary file). See the comment above
the command definition for notes on usage.
Define <D-r> and <D-R> mappings for :Run to make it easier to invoke in
MacVim.
Define a command :Expand to display the --pretty expanded output for the
current file. This can be configured to use different pretty types. See
the comment above the command definition for notes on usage.
Create an autoload file and put function definitions there to speed up
load time.
bors [Wed, 18 Jun 2014 22:41:40 +0000 (22:41 +0000)]
auto merge of #15006 : alexcrichton/rust/fix-nightly, r=brson
The nightly builds on linux have been failing over the past few days due to a
malformed LD_LIBRARY_PATH. It appears that the underlying cause is that one of
the tests, dep-info-custom, recursively invokes make but the RUSTC variable
passed down has the string "$LD_LIBRARY_PATH". This is intended to read the
host's original LD_LIBRARY_PATH, but it appears that the makefile is eagerly
expanding the "$L" to nothing, causing the original host's LD_LIBRARY_PATH to be
ignored.
This fix removes passing the string "$LD_LIBRARY_PATH" and rather expands it
eagerly to ensure that escaping doesn't happen at a later stage. I'm still not
entirely sure why the makefile is interpreting the dollar as a variable, but
this seems to fix the issue.
Alex Crichton [Wed, 18 Jun 2014 15:47:44 +0000 (08:47 -0700)]
test: Attempt to fix nightly-linux
The nightly builds on linux have been failing over the past few days due to a
malformed LD_LIBRARY_PATH. It appears that the underlying cause is that one of
the tests, dep-info-custom, recursively invokes make but the RUSTC variable
passed down has the string "$LD_LIBRARY_PATH". This is intended to read the
host's original LD_LIBRARY_PATH, but it appears that the makefile is eagerly
expanding the "$L" to nothing, causing the original host's LD_LIBRARY_PATH to be
ignored.
This fix removes passing the string "$LD_LIBRARY_PATH" and rather expands it
eagerly to ensure that escaping doesn't happen at a later stage. I'm still not
entirely sure why the makefile is interpreting the dollar as a variable, but
this seems to fix the issue.