auto merge of #13600 : brandonw/rust/master, r=brson
When calling a function, or anything with nested parens,
default to cindent's indent. The least error-prone way I
could think of identifying this is to look for a line
that ends with a ',', as well as a non-zero number of
any character except parens before the comma, and
then an open paren.
This will overlap with the previous rule accounting for
function definitions, but that should be fine because
it is also using cindent.
auto merge of #13601 : mdinger/rust/readme, r=brson
Configure required git be installed so this should be added to the dependencies list. If it's only required when using git, a note could also be added.
When calling a function, or anything with nested parens,
default to cindent's indent. The least error-prone way I
could think of identifying this is to look for a line
that ends with a ',', as well as a non-zero number of
any character except parens before the comma, and
then an open paren.
This will overlap with the previous rule accounting for
function definitions, but that should be fine because
it is also using cindent.
Alex Crichton [Thu, 17 Apr 2014 22:28:14 +0000 (15:28 -0700)]
std: Make ~[T] no longer a growable vector
This removes all resizability support for ~[T] vectors in preparation of DST.
The only growable vector remaining is Vec<T>. In summary, the following methods
from ~[T] and various functions were removed. Each method/function has an
equivalent on the Vec type in std::vec unless otherwise stated.
auto merge of #13585 : brandonw/rust/patch-1, r=cmr
The original text stated that one should only return a unique or managed pointer if you were given one in the first place. This makes it sound as if the function *should* return a unique pointer if it were given a unique pointer. The rest of the section goes on to describe why this is bad, and the example of bad code does exactly what the rule just said to do.
I reworded the original rule into a reference to the more concise rule mentioned at the bottom of the section, which helps add emphasis (a la 'it bears repeating').
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.
The original text stated that one should only return a unique or managed pointer if you were given one in the first place. This makes it sound as if the function *should* return a unique pointer if it were given a unique pointer. The rest of the section goes on to describe why this is bad, and the example of bad code does exactly what the rule just said to do.
I reworded the original rule into a reference to the more concise rule mentioned at the bottom of the section, which helps add emphasis (a la 'it bears repeating').
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.
projects / rust.git / log