bors [Sun, 3 Mar 2013 04:12:36 +0000 (20:12 -0800)]
auto merge of #5203 : erickt/rust/incoming, r=brson
My merges for #5143 missed a couple other copies. This patch corrects this, and gets stage0 to compile libsyntax with `#[deny(vecs_implicitly_copyable)]`. stage1 still fails though.
bors [Sat, 2 Mar 2013 23:33:39 +0000 (15:33 -0800)]
auto merge of #5198 : youknowone/rust/repeat-count, r=brson
Before:
````
test.rs:3:21: 3:30 error: expected constant integer for repeat count but found variable
test.rs:3 let a = ~[0, ..n]; //~ ERROR expected constant integer for repeat count but found variable
^~~~~~~~~
````
After:
````
test.rs:3:27: 3:28 error: expected constant integer for repeat count but found variable
test.rs:3 let a = ~[0, ..n]; //~ ERROR expected constant integer for repeat count but found variable
^
````
bors [Sat, 2 Mar 2013 16:30:41 +0000 (08:30 -0800)]
auto merge of #5143 : erickt/rust/incoming, r=pcwalton
Good morning,
It's taken a long time, but I finally am almost done freeing libsyntax of `vecs_implicitly_copyable` in this pull request, but I'm running into some issues. I've confirmed that all but the last commit (which only disables `vecs_implicitly_copyable` pass the `check` tests. The last commit errors with this message, which makes no sense to me:
```
/Users/erickt/rust/rust/src/libcore/num/f32.rs:35:37: 35:43 error: expected `,` but found `=`
/Users/erickt/rust/rust/src/libcore/num/f32.rs:35 pub pure fn $name($( $arg : $arg_ty ),*) -> $rv {
^~~~~~
```
and this stack trace:
```
#1 0x00000001000b059b in sys::begin_unwind_::_a923ca4ae164c::_06 ()
#2 0x00000001000b0542 in sys::begin_unwind::anon::anon::expr_fn_13876 ()
#3 0x00000001000048a1 in sys::begin_unwind::_8ec273289fc0adc0::_06 ()
#4 0x00000001005df999 in diagnostic::__extensions__::meth_7941::span_fatal::_efdf2d14612d79ec::_06 ()
#5 0x0000000100682d48 in parse::parser::__extensions__::meth_16938::fatal::_8aa3239426747a3::_06 ()
#6 0x00000001006850b8 in parse::common::__extensions__::meth_17005::expect::_d3604ec6c7698d5f::_06 ()
#7 0x00000001006b59f1 in parse::common::__extensions__::parse_seq_to_before_end_17860::_48c79835f9eb1011::_06 ()
#8 0x00000001006a50f7 in parse::parser::__extensions__::meth_17606::parse_fn_decl::_14f3785fe78967d::_06 ()
#9 0x00000001006b6f59 in parse::parser::__extensions__::meth_17987::parse_item_fn::_8a6be529cf7b2ca5::_06 ()
#10 0x00000001006ac839 in parse::parser::__extensions__::meth_17761::parse_item_or_view_item::_bfead947d6dd7d25::_06 ()
#11 0x00000001006c8b8f in parse::parser::__extensions__::meth_18364::parse_item::_96b54e33f65abe76::_06 ()
#12 0x000000010076179f in ext::tt::macro_rules::add_new_extension::generic_extension::anon::anon::expr_fn_23365 ()
#13 0x000000010072e793 in ext::expand::expand_item_mac::_a4f486c4465cfb1b::_06 ()
#14 0x00000001007b5ad3 in __morestack ()
```
There also a bunch of new warnings that I haven't cleaned up yet: https://gist.github.com/erickt/5048251.
@nikomatsakis thought there might be some scary bug in the parser caused by moving a vector in the parser instead of copying it, which is why I'm filing this pull request before it's ready. Thanks for any help!
bors [Sat, 2 Mar 2013 13:15:39 +0000 (05:15 -0800)]
auto merge of #5196 : thestinger/rust/ord, r=catamorphism
This allows `TreeMap`/`TreeSet` to fully express their requirements and reduces the comparisons from ~1.5 per level to 1 which really helps for string keys.
I also added `ReverseIter` to the prelude exports because I forgot when I originally added it.
bors [Sat, 2 Mar 2013 12:21:38 +0000 (04:21 -0800)]
auto merge of #5137 : yjh0502/rust/empty_struct, r=nikomatsakis
The fix is straight-forward, but there are several changes
while fixing the issue.
1) disallow `mut` keyword when making a new struct
In code base, there are following code,
```rust
struct Foo { mut a: int };
let a = Foo { mut a: 1 };
```
This is because of structural record, which is
deprecated corrently (see issue #3089) In structural
record, `mut` keyword should be allowd to control
mutability. But without structural record, we don't
need to allow `mut` keyword while constructing struct.
2) disallow structural records in parser level
This is related to 1). With structural records, there
is an ambiguity between empty block and empty struct
To solve the problem, I change parser to stop parsing
structural records. I think this is not a problem,
because structural records are not compiled already.
Misc. issues
There is an ambiguity between empty struct vs. empty match stmt.
with following code,
```rust
match x{} {}
```
Two interpretation is possible, which is listed blow
```rust
match (x{}) {} // matching with newly-constructed empty struct
(match x{}) {} // matching with empty enum(or struct) x
// and then empty block
```
It seems that there is no such code in rust code base, but
there is one test which uses empty match statement:
https://github.com/mozilla/rust/blob/incoming/src/test/run-pass/issue-3037.rs
All other cases could be distinguished with look-ahead,
but this can't be. One possible solution is wrapping with
parentheses when matching with an uninhabited type.
```rust
enum what { }
fn match_with_empty(x: what) -> ~str {
match (x) { //use parentheses to remove the ambiguity
}
}
```
bors [Sat, 2 Mar 2013 11:06:38 +0000 (03:06 -0800)]
auto merge of #5193 : sethpink/rust/struct-tup-pp, r=catamorphism
- Removed space between struct name and parentheses
- Fixed indentation of the rest of the file (missing end)
- Don't print parentheses for structs with no fields
- Added test
bors [Sat, 2 Mar 2013 09:00:41 +0000 (01:00 -0800)]
auto merge of #5188 : ben0x539/rust/doc-call-generic-fn, r=catamorphism
I have seen a few people confused on how to explicitly instantiate generic functions, since the syntax differs from C++'s and C#'s, which is probably where most people asking questions about generic functions are coming from. The only use of the `::<T>` syntax in the reference right now is in the section on paths, which is possibly not where someone trying to find out about generic functions is going to start looking. The tutorial doesn't mention it at all, but I think it's all right to make the reference a tiny bit more redundant and avoid stuffing the tutorial with syntax details.
----
The "Generic functions" subsection mentions that generic functions are instantiated based on context, so let's also mention right away (with a link to the #paths section) that an explicit form is available.
This also adds an example that explicitly instantiates a generic function to the function call expression section.
Jeong YunWon [Sat, 2 Mar 2013 08:43:24 +0000 (17:43 +0900)]
Better highlight for repeat count error
Before:
````
test.rs:3:21: 3:30 error: expected constant integer for repeat count but found variable
test.rs:3 let a = ~[0, ..n]; //~ ERROR expected constant integer for repeat count but found variable
^~~~~~~~~
````
After:
````
test.rs:3:27: 3:28 error: expected constant integer for repeat count but found variable
test.rs:3 let a = ~[0, ..n]; //~ ERROR expected constant integer for repeat count but found variable
^
````
bors [Sat, 2 Mar 2013 08:06:41 +0000 (00:06 -0800)]
auto merge of #5187 : ben0x539/rust/docs-unit-struct, r=catamorphism
This adds a few words about unit-like struct types (`struct Foo;`) in the sections for `struct` items, structure expressions and structure types (and fixes an adjacent typo or two). The added text is at the same time triply redundant because of how the sections are split and rather brief because I don't think there's that much to say about field-less structs without digressing into `impl`s and generic functions and whatnot, but it's probably better than nothing for a start.
The added arm for the grammar of struct expressions is really awkward. It's just
| expr_path
which is clearly not unambiguously a struct expression, but it didn't feel right not to add anything to the grammar chunk (and I can't tell whether the arm for enum-like structs is somehow unambiguous with regular enum expressions, either). Is this okay?
bors [Sat, 2 Mar 2013 04:51:40 +0000 (20:51 -0800)]
auto merge of #5185 : ben0x539/rust/net-tcp-docs, r=brson
This changes various type_names to TypeNames and fixes the example for `tcp::accept` that was still using the old `match` syntax and `{|args| ...}` closures.
The `accept` example was fairly outdated. I was just going to stay away from all the IO things until the scheduler revamp lands, but `accept` is probably one of the obvious starting points for networking stuff for a learner, and I don't want to get in the way of anyone's enthusiasm.
Doesn't touch non-comment lines, so I hope I will get away without learning about unit tests. It doesn't seem like the test system is set up to extract tests from doc comments right now.
Seth Pink [Sat, 2 Mar 2013 02:42:02 +0000 (12:42 +1000)]
Fix some struct-tuple def prettyprint issues
- Removed space between struct name and parentheses
- Fixed indentation of the rest of the file (missing end)
- Don't print parentheses for structs with no fields
- Added test
Benjamin Herr [Sat, 2 Mar 2013 00:07:01 +0000 (01:07 +0100)]
doc/rust.md: Demonstrate the `f::<T>()` syntax more often
The "Generic functions" subsection mentions that generic functions are
instantiated based on context, so let's also mention right away (with a
link to the #paths section) that an explicit form is available.
This also adds an example to the function call expression section that
explicitly instantiates a generic function.
Benjamin Herr [Fri, 1 Mar 2013 20:27:08 +0000 (21:27 +0100)]
`std::net::tcp` docs: Use current syntax and types
Doesn't touch non-comment lines. This changes various type_names to TypeNames
and fixes the example for `tcp::accept` that was still using the old
`match` syntax and `{|args| ...}` closures.
bors [Fri, 1 Mar 2013 01:21:40 +0000 (17:21 -0800)]
auto merge of #5176 : brson/rust/unwrap_shared_mutable_state, r=nikomatsakis
r?
This fixes the current [random failures](http://buildbot.rust-lang.org/builders/auto-linux/builds/291/steps/test/logs/stdio) on the bots and closes #4436 by removing `unwrap_shared_mutable_state` and the code that depends on it. The result is that ARC-like things will not be unwrappable. This feature is complex and is not used outside of test cases.
bors [Thu, 28 Feb 2013 23:21:41 +0000 (15:21 -0800)]
auto merge of #5113 : alexcrichton/rust/issue-4366, r=catamorphism
The first two commits are the actual fix going into place, and the last is just dealing with the fallout in the rest of the compiler.
The test added in the first two commits had 0 failures before this patch, and if the glob imports were changed to explicit imports then the errors showed up. Due to this behavior, I figured that the desired behavior was for glob imports to not accidentally leak a lot of non-public imports/functions/types into other modules.
There was quite a lot of fallout, and it all passes `make check` locally, but I doubt that it will pass on all platforms because there's probably some guarded off thing I missed.
I plan on making another patch soon which changes the default level of `unused_imports` to `warn` which will hopefully reduce a lot of the `use` noise throughout. In conjunction with #5104, and a few minor fixes, I think that the default level of `warn` is actually really usable.
Niko Matsakis [Thu, 28 Feb 2013 00:28:37 +0000 (19:28 -0500)]
Change bare functions so that they are represented by a single pointer.
The basic idea is that we add a new kind of adjustment, AutoAddEnv, that pads
an extern fn into a closure by adding the extra NULL word. Then there are a few
misc changes in trans to get the LLVM types to match up.
bors [Thu, 28 Feb 2013 07:30:40 +0000 (23:30 -0800)]
auto merge of #5155 : bstrie/rust/dedrop, r=pcwalton
This removes all but 6 uses of `drop {}` from the entire codebase. Removing any of the remaining uses causes various non-trivial bugs; I'll start reporting them once this gets merged.
bors [Thu, 28 Feb 2013 04:39:39 +0000 (20:39 -0800)]
auto merge of #5098 : pkgw/rust/pr/issue4869, r=brson
See issue #4869. I'm not quite sure what constitutes "consensus from the core team" (cf. discussion in the issue), but this at least demonstrates that the proposed change is pretty straightforward.
After this change, there are no new test failures. I've un-ignored the `to_str` vectors test; it's not at all obvious to me why it'd be problematic, and it passes on my Linux machine.
bors [Thu, 28 Feb 2013 01:36:41 +0000 (17:36 -0800)]
auto merge of #5141 : nikomatsakis/rust/region-syntax-expl-lifetimes, r=nikomatsakis
Major changes are:
- replace ~[ty_param] with Generics structure, which includes
both OptVec<TyParam> and OptVec<Lifetime>;
- the use of syntax::opt_vec to avoid allocation for empty lists;
Niko Matsakis [Fri, 15 Feb 2013 05:50:03 +0000 (21:50 -0800)]
Introduce lifetime declarations into the lists of type parameters.
Major changes are:
- replace ~[ty_param] with Generics structure, which includes
both OptVec<TyParam> and OptVec<Lifetime>;
- the use of syntax::opt_vec to avoid allocation for empty lists;
projects / rust.git / log