Previous year range of 2011-2013 was based on file creation date. The
check_license python script, however, only accepts copyrights starting
in 2012 or later.
There were three issues effecting the example in the getopts rustdoc:
1. The blockquote was incorrectly formatted. Fixed by switching to using
an explicit markdown code section with ```.
2. The `fail fail_str(f)` would not compile. Fixed by using `fail!()` instead
of `fail`.
3. The line `matches.free[0]` produced a compile error about moving from
an immutable vector. Fix by using `copy`.
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
}
}
```
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.
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)
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.
* replace the dual next() and get() calls with a single next() function
* drop one of the pointer members from the struct
* add a method for using the lazy iterator with a for loop
* replace the dual next() and get() calls with a single next() function
* drop one of the pointer members from the struct
* add a method for using the lazy iterator with a for loop
These commits take the old bitv implementation and modernize it with an explicit self, some minor touchups, and using what I think is some more recent patterns (like `::new` instead of `Type()`).
Additionally, this adds an implementation of `container::Set` on top of a bit vector to have as a set of `uint`s. I initially tried to parameterize the type for the set to be `T: NumCast` but I was hitting build problems in stage0 which I think means that it's not in a snapshot yet, so it's just hardcoded as a set of `uint`s now. In the future perhaps it could be parameterized. I'm not sure if it would really add anything, though, so maybe it's nicer to be hardcoded anyway.
I also added some extra methods to do normal bit vector operations on the set in-place, but these aren't a part of the `Set` trait right now. I haven't benchmarked any of these operations just yet, but I imagine that there's quite a lot of room for optimization here and there.
* use a proper exported data type with private fields
* implement core::container::Container
* use the current constructor convention
* use explicit self
* get rid of DVec and the mutable fields
Closes#2343
Issue #3869
review? @nikomatsakis
Convert all uses of vec::slice to vec::view Issue #3869
Rename const_view to const_slice
Renamed mut_view to mut_slice
Fix windows build error. `buf` is borrowed by the call to
`as_mut_buf()` and so we must invoke `slice()` outside of that
call.
I removed the unused wrappers methods named `calloc` because they relied on the malloc wrapper having a `bool zero = true` default parameter (which resulted in some accidental zeroing). Perhaps wrapping the actual calloc function would be useful, but I don't know of an existing use case that could use it so I just removed these.
This gives an ~1% performance improvement for TreeMap, which does a lot of small allocations. Vectors use `realloc` which didn't zero before these changes so there's no measurable change in performance.
This patch finishes removing inner vector mutability from the vast majority of the compiler. Exceptions:
* core::dvec: ideally this entire type will be able to be replaced by `~[]`, but Niko asked me to hold off on removing Dvecs until he makes some fixes to borrowed pointers.
* liveness: liveness.rs is an impenetrable neutron star of deprecated semantics.
* compile-fail: I'm not sure if a lot of these tests are testing inner mutability or mutability in general. I figure that RIMOVing this folder should wait until this syntax is removed from the parser.
I also took this chance to remove many of the inner-mutability-related functions from core::vec, or as many uses of those functions as possible where still necessary. consume_mut and append_mut have been axed. cast_to_mut and cast_from_mut are still needed in a few places.
r?
I added code to the JSON encoder to support the serialization of enums. Before this, the JSON serializer only handled Option, and encoded None as 'null'. Following this change, all enums are encoded as arrays containing the enum name followed by the encoded fields. This appears consistent with the unstated invariant that the resulting output can be mapped back to the input *if* there's a decoder around that knows the types that were in existence when the serialization occurred.
Also, added test cases.
Performance before:
std::treemap::TreeMap
sequential_ints 0.083971 s
random_ints 0.095861 s
delete_ints 0.083931 s
sequential_strings 0.278272 s
random_strings 0.240286 s
delete_strings 0.173581 s
Performance after:
std::treemap::TreeMap
sequential_ints 0.083297 s
random_ints 0.097644 s
delete_ints 0.052602 s
sequential_strings 0.287326 s
random_strings 0.242372 s
delete_strings 0.142269 s
Performance before:
std::treemap::TreeMap
sequential_ints 0.151877 s
random_ints 0.160926 s
delete_ints 0.08694 s
sequential_strings 0.316458 s
random_strings 0.290778 s
delete_strings 0.169892 s
Performance after:
std::treemap::TreeMap
sequential_ints 0.083971 s
random_ints 0.095861 s
delete_ints 0.083931 s
sequential_strings 0.278272 s
random_strings 0.240286 s
delete_strings 0.173581 s
...ear
values to be copied. Rewrite kind computation so that instead of directly
computing the kind it computes what kinds of values are present in the type,
and then derive kinds based on that. I find this easier to think about.
Fixes#4821.
r? @catamorphism
values to be copied. Rewrite kind computation so that instead of directly
computing the kind it computes what kinds of values are present in the type,
and then derive kinds based on that. I find this easier to think about.
Fixes#4821.
