Turns out @ isn't valid for the ARM assembler.

Change fn() -> &fn().

Change fn() -> &fn().

There's no reason to make them executable, and this throws a warning
with the Arch Linux package lint tool (namcap) for .a files.

Closes #5643

There's no reason to make them executable, and this throws a warning
with the Arch Linux package lint tool (namcap) for .a files.

Fix typo and add fixed length vec changes.

Closes #5643

This also removes the need to pass noexecstack to gcc, but that wasn't
actually working anymore.

Fix typo and add fixed length vec changes.

Added char_range_at_reverse underflow test

Fixes #5423.

#5405

Also, renames the confusingly named `use_new_rt` in `libcore/unstable/lang.rs`

Closes #3549

The issue report has some reasoning, but I'd like to add that I don't think managed pointers belong in core. It's *possible* to write a safe doubly-linked list on top of `unsafe`, but it would be much more limited and I don't think there's much of a use case - it would lose a lot of flexibility. You're probably better off using a vector, hash table, tree, heap or ring buffer in almost every case.

Closes #3549

@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.

It's nice to make unsafe stand out, but this way isn't correct because it
highlights it in comments.

lifetimes and globals are now the only two places static is used, and
'static isn't matched by this

Continuing #5421

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.