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.
Before it wouldn't warn about unused imports in the list if something in the list was used. These commits fix that case, add a test, and remove all unused imports in lists of imports throughout the compiler.
As far as I can tell, this doesn't make rust compile any
faster, but it does at least remove one level of indirection
on malloc, which might help speed up some operations.
@nikomatsakis pointed out that `fn read_option<T>(&self, f: &fn() -> T) -> Option<T>` should have this syntax so it can work with custom option types: `fn read_option<T>(&self, f: &fn(bool) -> T) -> T`.
Also, this also includes some `#[inline(always)]` on the memory functions in `src/libcore/unstable/lang.rs` to reduce one level of indirection when allocating memory.
As far as I can tell, this doesn't make rust compile any
faster, but it does at least remove one level of indirection
on malloc, which might help speed up some operations.
This is needed so that hash tables can require strict equality but not require types to be ordered. It's a subset of the functionality of `TotalOrd` so I made that inherit from `TotalEq`.
