Most could use the each method, but because of the hack used to
disambiguate old- and new-style loops, some had to use vec::each.
(This hack will go away soon.)
Issue #1619
- Move io, run and rand to core.
- Remove incorrect ctypes module (use libc).
- Remove os-specific modules for os and fs.
- Split fs between core::path and core::os.
This required changing almost all users of hashmaps to import the hashmap interface first.
The `size` member in the hashmap structure was renamed to `count` to work around a name conflict.
This required changing almost all users of hashmaps to import the hashmap interface first.
The `size` member in the hashmap structure was renamed to `count` to work around a name conflict.
Our json implementation did not conform to the spec, and
was missing support for escpaed characters and exponental
numbers. This fixes it, and adds support for reading/writing
json directly from/to a stream.
There are two things left unimplemented. We could use a
"to_json" iface/impl, but that really needs traits to cut
down on code duplication. The other is it wouldn't be that
not that hard to turn this implementation into a event driven
parser like YAJL, but I ran into some type-inference bugs,
so I cut that out. It'd be nice to revisit this in the future
though.
* -g or --mode=user to create/use .cargo under $HOME
* -G or --mode=system to create/use .cargo under sysroot
* by default, `cargo` uses .cargo under current working directory
* Renamed str::split -> str::split_byte
* Renamed str::splitn -> str::splitn_byte
* Renamed str::split_func -> str::split
* Renamed str::split_char -> str::split_char
* Renamed str::split_chars_iter -> str::split_char_iter
* Added u8::is_ascii
* Fixed the behavior of str::split_str, so that it matches split_chars
and split (i.e. ["", "XXX", "YYY", ""] == split_str(".XXX.YYY.", "."))
* Fixed str::split_byte and str::splitn_byte so that they handle
splitting UTF-8 strings on a given UTF-8/ASCII byte and also handle ""
as the others do
Now that core exports "option" as a synonym for option::t, search-and-
replace option::t with option.
The only place that still refers to option::t are the modules in libcore
that use option, because fixing this requires a new snapshot
(forthcoming).
The former contain a codemap (which is per-crate), and the latter don't. This
will be useful in order to allow more than one crate to be compiled in one run
of the compiler.
