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
^
````
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.
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
}
}
```
- 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
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
^
````
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.
- 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
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.
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.
Note that there is not consensus to remove it.
(second commit)
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.
