auto merge of #13565 : alexcrichton/rust/issue-13560, r=brson
Syntax-only crates are no longer registered with the cstore, so there's no need
to allocate crate numbers to them. This ends up leaving gaps in the crate
numbering scheme which is not expected in the rest of the compiler.
auto merge of #13261 : pnkfelix/rust/fsk-fix-12856, r=nikomatsakis
Fix #12856.
I wanted to put this up first because I wanted to get feedback about the second commit in the series, commit 8599236. Its the more invasive part of the patch and is largely just belt-and-suspenders assertion checking; in the commit message I mentioned at least one other approach we could take here. Or we could drop the belt-and-suspenders and just rely on the guard added in the first patch, commit 8d6a005 (which is really quite trivial on its own).
So any feedback on what would be better is appreciated.
This version of `is_to_be_inferred` double-checks the result from
`inferred_map` by querying the `named_region_map` and `ast_map` and
then asserts that the `inferred_map` state is consistent with its own
findings. (See issue 13261 for further discussion of the approaches).
auto merge of #13567 : iancormac84/rust/libc_windows_guid_fix, r=alexcrichton
structure's Data2 and Data3 members expect WORD types instead of DWORD. I
discovered this discrepancy while experimenting with some bindings to
Microsoft's OLE2 api. The discrepancy was corrupting the contents of the
string returned by UuidToString after I used known GUIDs to test the
accuracy of the function binding. I didn't add test cases because it would
mean adding a dependency to my rather incomplete binding library. However,
the fix produces expected string values when tested.
auto merge of #13563 : lifthrasiir/rust/refman-dl, r=alexcrichton
Closes #13561. All definition lists have been converted to unordered lists. This is a temporary measure; please revert this when Sundown (or any replacement) gets a support for definition lists in the future.
Extended `syntax::{fold, ast_map}` to include lifetimes.
Part of this required added an override of `fold_type_method` in the
Folder for Ctx impl; it follows the same pattern as `fold_method`.
Also, as a drive-by fix, I moved all of the calls to `folder.new_id`
in syntax::fold's no-op default traversal to really be the first
statement in each function.
* This is to uphold the invariant that `folder.new_id` is always
called first (an unfortunate requirement of the current `ast_map`
code), an invariant that we seemingly were breaking in e.g. the
previous `noop_fold_block`.
* Now it should be easier to see when adding new code that this
invariant must be upheld.
* (note that the breakage in `noop_fold_block` may not have mattered
so much previously, since the only thing that blocks can bind are
lifetimes, which I am only adding support for now.)
auto merge of #13503 : edwardw/rust/lifetime-ice, r=nikomatsakis
When instantiating trait default methods for certain implementation,
`typeck` correctly combined type parameters from trait bound with those
from method bound, but didn't do so for lifetime parameters. Applies
the same logic to lifetime parameters.
auto merge of #13485 : adrientetar/rust/newrustdoc, r=brson
- Cherry-pick from #12996
- Use Fira Sans for headlines and sidebar (Light), Heuristica for the body (Adobe Utopia derivative). Both are licensed under the SIL OFL license.
- A few tweaks
Two examples: [modified `std`](http://adrientetar.legtux.org/cached/rust-docs/std.htm) and [modified `std::io`](http://adrientetar.legtux.org/cached/rust-docs/io.htm).
cc #13484
**Blocked on graydon/rust-www#25 (for hosting of the fonts), that's showcased [here](http://adrientetar.github.io/rust-www/).**
auto merge of #13465 : alexcrichton/rust/fix-comm-dox, r=brson
Some of this documentation got a little out of date. There was no mention of a
`SyncSender`, and the entire "Outside the runtime" section isn't really true any
more (or really all that relevant).
This also updates a few other doc blocks and adds some examples.
auto merge of #13432 : ruediger/rust/rustmode, r=nikomatsakis
* Use `setq-local` instead of `(set (make-local-variable 'var) value)`. Provides a version for older Emacsen.
* Remove use of `cl.el`.
* Use \' in file regexp instead of line end match $.
* Use type for `defcustom` and add parent group.
auto merge of #13418 : ktt3ja/rust/move-out-of, r=brson
This commit changes the way move errors are reported when some value is
captured by a PatIdent. First, we collect all of the "cannot move out
of" errors before reporting them, and those errors with the same "move
source" are reported together. If the move is caused by a PatIdent (that
binds by value), we add a note indicating where it is and suggest the
user to put `ref` if they don't want the value to move. This makes the
"cannot move out of" error in match expression nicer (though the extra
note may not feel that helpful in other places :P). For example, with
the following code snippet,
fn main() {
let f = &Foo1(~1u32, ~2u32);
match *f {
Foo1(num1, num2) => (),
Foo2(num) => (),
Foo3 => ()
}
}
```
Errors before the change:
```rust
test.rs:10:9: 10:25 error: cannot move out of dereference of `&`-pointer
test.rs:10 Foo1(num1, num2) => (),
^~~~~~~~~~~~~~~~
test.rs:10:9: 10:25 error: cannot move out of dereference of `&`-pointer
test.rs:10 Foo1(num1, num2) => (),
^~~~~~~~~~~~~~~~
test.rs:11:9: 11:18 error: cannot move out of dereference of `&`-pointer
test.rs:11 Foo2(num) => (),
^~~~~~~~~
```
After:
```rust
test.rs:9:11: 9:13 error: cannot move out of dereference of `&`-pointer
test.rs:9 match *f {
^~
test.rs:10:14: 10:18 note: attempting to move value to here (to prevent the move, use `ref num1` or `ref mut num1` to capture value by reference)
test.rs:10 Foo1(num1, num2) => (),
^~~~
test.rs:10:20: 10:24 note: and here (use `ref num2` or `ref mut num2`)
test.rs:10 Foo1(num1, num2) => (),
^~~~
test.rs:11:14: 11:17 note: and here (use `ref num` or `ref mut num`)
test.rs:11 Foo2(num) => (),
^~~
```
This is a Windows specific fix in libc. According to MSDN, the GUID
structure's Data2 and Data3 members expect WORD types instead of DWORD. I
discovered this discrepancy while experimenting with some bindings to
Microsoft's OLE2 api. The discrepancy was corrupting the contents of the
string returned by UuidToString after I used known GUIDs to test the
accuracy of the function binding. I didn't add test cases because it would
mean adding a dependency to my rather incomplete binding library. However,
the fix produces expected string values when tested.
Alex Crichton [Wed, 16 Apr 2014 18:42:22 +0000 (11:42 -0700)]
rustc: Don't allocate a cnum to syntax crates
Syntax-only crates are no longer registered with the cstore, so there's no need
to allocate crate numbers to them. This ends up leaving gaps in the crate
numbering scheme which is not expected in the rest of the compiler.
auto merge of #13454 : brson/rust/noglobs, r=alexcrichton
Them removes all the glob reexports from liblibc. I did it by removing them all, and then adding back per-platform explicit reexports until everything built again.
I realize this isn't the best strategy for determining an API, but this is the lowest-impact change that solves the problem, plus I'm dissatisfied with the design of this library for other reasons and think it needs to be reconsidered from top to bottom (later).
Edward Wang [Mon, 14 Apr 2014 00:33:04 +0000 (08:33 +0800)]
Combine lifetime parameters when instantiating default methods
When instantiating trait default methods for certain implementation,
`typeck` correctly combined type parameters from trait bound with those
from method bound, but didn't do so for lifetime parameters. Applies
the same logic to lifetime parameters.
Alex Crichton [Wed, 16 Apr 2014 01:02:58 +0000 (18:02 -0700)]
rustc: Remove private enum variants
This removes the `priv` keyword from the language and removes private enum
variants as a result. The remaining use cases of private enum variants were all
updated to be a struct with one private field that is a private enum.
auto merge of #13539 : Aatch/rust/vector-copy-faster, r=thestinger
LLVM wasn't recognising the loops as memcpy loops and was therefore failing to optimise them properly. While improving LLVM is the "proper" way to fix this, I think that these cases are important enough to warrant a little low-level optimisation.
Fixes #13472
r? @thestinger
---
Benchmark Results:
```
--- Before ---
test clone_owned ... bench: 6126104 ns/iter (+/- 285962) = 170 MB/s
test clone_owned_to_owned ... bench: 6125054 ns/iter (+/- 271197) = 170 MB/s
test clone_str ... bench: 80586 ns/iter (+/- 11489) = 13011 MB/s
test clone_vec ... bench: 3903220 ns/iter (+/- 658556) = 268 MB/s
test test_memcpy ... bench: 69401 ns/iter (+/- 2168) = 15108 MB/s
--- After ---
test clone_owned ... bench: 70839 ns/iter (+/- 4931) = 14801 MB/s
test clone_owned_to_owned ... bench: 70286 ns/iter (+/- 4836) = 14918 MB/s
test clone_str ... bench: 78519 ns/iter (+/- 5511) = 13353 MB/s
test clone_vec ... bench: 71415 ns/iter (+/- 1999) = 14682 MB/s
test test_memcpy ... bench: 70980 ns/iter (+/- 2126) = 14772 MB/s
```
auto merge of #13527 : huonw/rust/macro-expander-trait, r=sfackler
There's now one unified way to return things from a macro, instead of
being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr`
variants of the `MacResult` enum. This does simplify the logic handling
the expansions, but the biggest value of this is it makes macros in (for
example) type position easier to implement, as there's this single thing
to modify.
By my measurements (using `-Z time-passes` on libstd and librustc etc.),
this appears to have little-to-no impact on expansion speed. There are
presumably larger costs than the small number of extra allocations and
virtual calls this adds (notably, all `macro_rules!`-defined macros have
not changed in behaviour, since they had to use the `AnyMacro` trait
anyway).
---
Summary of changes for dynamic syntax extension maintainers:
- `MacResult` is now a trait, and is returned as `~MacResult`
- `MRExpr` & `MRItem` are now `MacExpr::new` and `MacItem:new` respectively (which return `~MacResult`s)
- `MacResult::dummy_...` is `DummyResult::any` or `DummyResult::expr`
auto merge of #13522 : seanmonstar/rust/sip, r=alexcrichton
work started from @gereeter's PR: https://github.com/mozilla/rust/pull/13114
but adjusted bits
```
before
test hash::sip::tests::bench_u64 ... bench: 34 ns/iter (+/- 0)
test hash::sip::tests::bench_str_under_8_bytes ... bench: 37 ns/iter (+/- 1)
test hash::sip::tests::bench_str_of_8_bytes ... bench: 43 ns/iter (+/- 1)
test hash::sip::tests::bench_str_over_8_bytes ... bench: 50 ns/iter (+/- 1)
test hash::sip::tests::bench_long_str ... bench: 613 ns/iter (+/- 14)
test hash::sip::tests::bench_compound_1 ... bench: 114 ns/iter (+/- 11)
after
test hash::sip::tests::bench_u64 ... bench: 25 ns/iter (+/- 0)
test hash::sip::tests::bench_str_under_8_bytes ... bench: 31 ns/iter (+/- 0)
test hash::sip::tests::bench_str_of_8_bytes ... bench: 36 ns/iter (+/- 0)
test hash::sip::tests::bench_str_over_8_bytes ... bench: 40 ns/iter (+/- 0)
test hash::sip::tests::bench_long_str ... bench: 600 ns/iter (+/- 14)
test hash::sip::tests::bench_compound_1 ... bench: 64 ns/iter (+/- 6)
```
Notably it seems smaller keys will hash faster. A long string doesn't see much gains, but compound cuts in half (once compound used a `int` and `u64`).
Huon Wilson [Tue, 15 Apr 2014 12:00:14 +0000 (22:00 +1000)]
syntax: unify all MacResult's into a single trait.
There's now one unified way to return things from a macro, instead of
being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr`
variants of the `MacResult` enum. This does simplify the logic handling
the expansions, but the biggest value of this is it makes macros in (for
example) type position easier to implement, as there's this single thing
to modify.
By my measurements (using `-Z time-passes` on libstd and librustc etc.),
this appears to have little-to-no impact on expansion speed. There are
presumably larger costs than the small number of extra allocations and
virtual calls this adds (notably, all `macro_rules!`-defined macros have
not changed in behaviour, since they had to use the `AnyMacro` trait
anyway).
auto merge of #13390 : alexcrichton/rust/run-some-destructors, r=brson
Previously, if statements of the form "Foo;" or "let _ = Foo;" were encountered
where Foo had a destructor, the destructors were not run. This changes
the relevant locations in trans to check for ty::type_needs_drop and invokes
trans_to_lvalue instead of trans_into.
Alex Crichton [Wed, 16 Apr 2014 01:25:38 +0000 (18:25 -0700)]
workcache: Don't assume gcc exists on all platforms
FreeBSD has recently moved to clang by default, and no longer ship gcc. Instead
use "cc" on unix platforms (the default compiler) and "gcc" on windows.
Huon Wilson [Mon, 14 Apr 2014 10:04:14 +0000 (20:04 +1000)]
Use the unsigned integer types for bitwise intrinsics.
Exposing ctpop, ctlz, cttz and bswap as taking signed i8/i16/... is just
exposing the internal LLVM names pointlessly (LLVM doesn't have "signed
integers" or "unsigned integers", it just has sized integer types
with (un)signed *operations*).
These operations are semantically working with raw bytes, which the
unsigned types model better.
Alex Crichton [Mon, 14 Apr 2014 14:06:14 +0000 (07:06 -0700)]
native: Fix a race in select()
During selection, libnative would erroneously re-acquire ownership of a task
when a separate thread still had ownership of the task. The loop in select()
was rewritten to acknowledge this race and instead block waiting to re-acquire
ownership rather than plowing through.
Kang Seonghoon [Mon, 14 Apr 2014 18:39:59 +0000 (03:39 +0900)]
rustdoc: Better sorting criteria for searching.
This essentially rewrites the sorting algorithm, which relied on
the implementation-defined handling of non-consistent sorting function
(cf. ECMA-262 5th edition, section 15.4.4.11)
and was also a bit inefficient.
The new criteria expands the prior criteria while adding these ones:
- The current crate is always preferred over other crates.
(Closes #13178)
- An item with a description is preferred over one without it,
if item names match. This is a heuristic assuming that
the documented item is more likely to be relevant.
- An item with no literal occurrence of search query is handled correctly.
Alex Crichton [Mon, 14 Apr 2014 20:42:45 +0000 (13:42 -0700)]
mk: Change windows to install from stage2
In the past, windows was installed from stage3 to guarantee convergence between
the host and target artifacts, but syntax extensions on all platforms are
currently relying on convergence, so special casing this one platform has become
less relevant over time.
This will also have the added benefit of dealing with #13474 and #13491. These
issues will be closed after next next nightly is confirmed to fix them.
auto merge of #13511 : Meyermagic/rust/enum_typeid, r=alexcrichton
Fixes #13507.
I haven't familiarized myself with this part of the rust compiler, so hopefully there are no mistakes (despite the simplicity of the commit). It is also 5am.
auto merge of #13164 : ktt3ja/rust/lifetime-suggestion-method, r=nmatsakis
This includes a change to the way lifetime names are generated. Say we
figure that `[#0, 'a, 'b]` have to be the same lifetimes, then instead
of just generating a new lifetime `'c` like before to replace them, we
would reuse `'a`. This is done so that when the lifetime name comes
from an impl, we don't give something that's completely off, and we
don't have to do much work to figure out where the name came from. For
example, for the following code snippet:
`[#1, 'x]` (where `#1` is BrAnon(1) and refers to lifetime of `&int`)
have to be marked the same lifetime. With the old method, we would
generate a new lifetime `'a` and suggest `fn baz1(&self) -> &'a int`
or `fn baz1<'a>(&self) -> &'a int`, both of which are wrong.
Kiet Tran [Wed, 26 Mar 2014 23:12:50 +0000 (19:12 -0400)]
Support lifetime suggestion for method
This includes a change to the way lifetime names are generated. Say we
figure that `[#0, 'a, 'b]` have to be the same lifetimes, then instead
of just generating a new lifetime `'c` like before to replace them, we
would reuse `'a`. This is done so that when the lifetime name comes
from an impl, we don't give something that's completely off, and we
don't have to do much work to figure out where the name came from. For
example, for the following code snippet:
`[#1, 'x]` (where `#1` is BrAnon(1) and refers to lifetime of `&int`)
have to be marked the same lifetime. With the old method, we would
generate a new lifetime `'a` and suggest `fn baz1(&self) -> &'a int`
or `fn baz1<'a>(&self) -> &'a int`, both of which are wrong.
auto merge of #13489 : JustAPerson/rust/crate-file-name, r=alexcrichton
Before, the `--crate-file-name` flag only checked crate attributes for
possible crate types. Now, if any type is specified by one or more
`--crate-type` flags, only the filenames for those types will be
emitted, and any types specified by crate attributes will be ignored.
Alex Crichton [Fri, 11 Apr 2014 19:59:30 +0000 (12:59 -0700)]
std: Update documentation on the `comm` module
Some of this documentation got a little out of date. There was no mention of a
`SyncSender`, and the entire "Outside the runtime" section isn't really true any
more (or really all that relevant).
This also updates a few other doc blocks and adds some examples.
auto merge of #13416 : brson/rust/30min, r=alexcrichton
This is intended to be the first thing somebody new to the language reads about Rust. It is supposed to be simple and intriguing, to give the user an idea of whether Rust is appropriate for them, and to hint that there's a lot of cool stuff to learn if they just keep diving deeper.
I'm particularly happy with the sequence of concurrency examples.
Before, normal compilation and the --crate-file-name flag would
generate output based on both #![crate_type] attributes and
--crate-type flags. Now, if one or more flag is specified by command
line, only those will be used.
auto merge of #13496 : alexcrichton/rust/issue-13495, r=sfackler
This bug was introduced in #13384 by accident, and this commit continues the
work of #13384 by finishing support for loading a syntax extension crate without
registering it with the local cstore.
auto merge of #13480 : edwardw/rust/vtable-ice, r=alexcrichton
A mismatched type with more type parameters than the expected one causes
`typeck` looking up out of the bound of type parameter vector, which
leads to ICE.
auto merge of #13431 : lifthrasiir/rust/rustdoc-smaller-index, r=alexcrichton
This is a series of inter-related commits which depend on #13402 (Prune the paths that do not appear in the index). Please consider this as an early review request; I'll rebase this when the parent PR get merged and rebase is required.
----
This PR aims at reducing the search index without removing the actual information. In my measurement with both library and compiler docs, the search index is 52% smaller before gzipped, and 16% smaller after gzipped:
``` 1719473 search-index-old.js 1503299 search-index.js (after #13402, 13% gain)
724955 search-index-new.js (after this PR, 52% gain w.r.t. #13402)
262711 search-index-old.js.gz
214205 search-index.js.gz (after #13402, 18.5% gain)
179396 search-index-new.js.gz (after this PR, 16% gain w.r.t. #13402)
```
Both the uncompressed and compressed size of the search index have been accounted. While the former would be less relevant when #12597 (Web site should be transferring data compressed) is resolved, the uncompressed index will be around for a while anyway and directly affects the UX of docs. Moreover, LZ77 (and gzip) can only remove *some* repeated strings (since its search window is limited in size), so optimizing for the uncompressed size often has a positive effect on the compressed size as well.
Each commit represents the following incremental improvements, in the order:
1. Parent paths were referred by its AST `NodeId`, which tends to be large. We don't need the actual node ID, so we remap them to the smaller sequential numbers. This also means that the list of paths can be a flat array instead of an object.
2. We remap each item type to small predefined numbers. This is strictly intended to reduce the uncompressed size of the search index.
3. We use arrays instead of objects and reconstruct the original objects in the JavaScript code. Since this removes a lot of boilerplates, this affects both the uncompressed and compressed size.
4. (I've found that a centralized `searchIndex` is easier to handle in JS, so I shot one global variable down.)
5. Finally, the repeated paths in the consecutive items are omitted (replaced by an empty string). This also greatly affects both the uncompressed and compressed size.
There had been several unsuccessful attempts to reduce the search index. Especially, I explicitly avoided complex optimizations like encoding paths in a compressed form, and only applied the optimizations when it had a substantial gain compared to the changes. Also, while I've tried to be careful, the lack of proper (non-smoke) tests makes me a bit worry; any advice on testing the search indices would be appreciated.
Kang Seonghoon [Wed, 9 Apr 2014 08:16:09 +0000 (17:16 +0900)]
rustdoc: Use an array instead of an object for the search index.
`buildIndex` JS function recovers them into the original object form.
This greatly reduces the size of the uncompressed search index (27%),
while this effect is less visible after gzipped (~5%).
auto merge of #13464 : alexcrichton/rust/fix-rustdoc-rendering, r=brson
Closures did not have their bounds printed at all, nor their lifetimes. Trait
bounds were also printed in angle brackets rather than after a colon with a '+'
inbetween them.
Note that on the current task::spawn [1] documentation page, there is no mention
of a `Send` bound even though it is crucially important!
projects / rust.git / log