rather than a tuple. The current setup iterates over
`BaseIter<(&'self K, &'self V)>` where 'self is a lifetime declared
*in the each method*. You can't place such a type in
the impl declaration. The compiler currently allows it,
but this will not be legal under #5656 and I'm pretty sure
it's not sound now.
It was simpler to just give the variants a value instead of listing out all the cases for (*self, *other) in a match statement or writing spaghetti code. This makes the `cmp` method easier to use with FFI too, since you're a cast away from an idiomatic C comparator function. It would be fine implemented another way though.
This removes some of the easier instances of mutable fields where the explicit self can just become `&mut self` along with removing some unsafe blocks which aren't necessary any more now that purity is gone.
Most of #4568 is done, except for [one case](https://github.com/alexcrichton/rust/blob/less-mut-fields/src/libcore/vec.rs#L1754) where it looks like it has to do with it being a `const` vector. Removing the unsafe block yields:
```
/Users/alex/code/rust2/src/libcore/vec.rs:1755:12: 1755:16 error: illegal borrow unless pure: creating immutable alias to const vec content
/Users/alex/code/rust2/src/libcore/vec.rs:1755 for self.each |e| {
^~~~
/Users/alex/code/rust2/src/libcore/vec.rs:1757:8: 1757:9 note: impure due to access to impure function
/Users/alex/code/rust2/src/libcore/vec.rs:1757 }
^
error: aborting due to previous error
```
I also didn't delve too much into removing mutable fields with `Cell` or `transmute` and friends.
Performing a deep copy isn't ever desired for a persistent data
structure, and it requires a more complex implementation to do
correctly. A deep copy needs to check for cycles to avoid an infinite
loop.
Performing a deep copy isn't ever desired for a persistent data
structure, and it requires a more complex implementation to do
correctly. A deep copy needs to check for cycles to avoid an infinite
loop.
A number like 0b1_1111_1111 == 511 would be parsed to Some(255u8) rather than None
by from_str_common, since 255 * 2 + 1 == 255 (mod 256) so the overflow wasn't detected.
Only applied to conversions where the radix was a power of 2, and where all digits
repeated.
Closes#5770.
bare function store (which is not in fact a kind of value) but rather
ty::TraitRef. Removes many uses of fail!() and other telltale signs of
type-semantic mismatch.
cc #4183 (not a fix, but related)
This pull request removes some mut-fields from at_vec, str, vec, unstable, and cell. Sadly in case of Cell this required using either transmute_mut (2 instances) or changing the interface. I chose the former. Perhaps it would be a good idea to merge Cell and Option, and take that opportunity to change the interface to use '&mut self' instead of '&self' (which would enable removing the transmutations) for take and put_back.
r?
This naming is free now that `oldmap` has finally been removed, so this is a search-and-replace to take advantage of that. It might as well be called `HashMap` instead of being named after the specific implementation, since there's only one.
SipHash distributes keys so well that I don't think there will ever be much need to use anything but a simple hash table with open addressing. If there *is* a better way to do it, it will probably be better in all cases and can just be the default implementation.
A cuckoo-hashing implementation combining a weaker hash with SipHash could be useful, but that won't be as general purpose - you would need to write a separate fast hash function specialized for the type to really take advantage of it (like taking a page from libstdc++/libc++ and just using the integer value as the "hash"). I think a more specific naming for a truly alternative implementation like that would be fine, with the nice naming reserved for the general purpose container.
When I submitted #5659, it apparently caused some test failures. Then, because I left it in my incoming rather than making a new branch, I deleted my commit.
Let's try this again, this time, with its own branch so that I don't screw it up.
r?
It seems nobody can figure out whether this is _supposed to_ make a difference anymore, and in testing it seems to work either way, so I removed it. One less alarming warning during a fresh build.
@nikomatsakis and I were talking about how the serializers were a bit too complicated. None of the users of With the `emit_option` and `read_option` functions, the serializers are now moving more high level. This patch series continues that trend. I've removed support for emitting specific string and vec types, and added support for emitting mapping types.
I believe this patch incorporates all expected syntax changes from extern
function reform (#3678). You can now write things like:
extern "<abi>" fn foo(s: S) -> T { ... }
extern "<abi>" mod { ... }
extern "<abi>" fn(S) -> T
The ABI for foreign functions is taken from this syntax (rather than from an
annotation). We support the full ABI specification I described on the mailing
list. The correct ABI is chosen based on the target architecture.
Calls by pointer to C functions are not yet supported, and the Rust type of
crust fns is still *u8.
