Improved the tags impl regex
collections, unicode: Add support for NFC and NFKC
Fix alignment tests for ARM on Linux. #14848
Use cargo new.

Now that this feature exists, we should use it.

Fixes #16078
Add note about Cargo.lock
Add a split_at method to slice::ImmutableVector

This method is similar to the mut_split_at method of slice::MutableVector.
Fix manual regarding attribute placement.

Fixes #15494.
Rewrite read_u32v_be() and write_u32_be() to make sure that all memory access is properly aligned
Remove unused tuple struct
Sort .gitignore.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
Use globs to ignore target directories.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
time::Tm should impl Eq in addition to PartialEq
native: Fix utime() for windows

Apparently the units are in milliseconds, not in seconds!
fix underflow in vec swap_remove
fixes #16200
auto merge of #16186 : steveklabnik/rust/guide_cargo_new, r=alexcrichton

Two commits here: one to add `cargo new` to the guide, and a second to mention the lockfile that Cargo now generates.
auto merge of #16189 : steveklabnik/rust/gh15494, r=alexcrichton

Fixes #15494.
rustdoc: Add generator meta tag to API docs

This is consistent with the meta tag in Markdown docs run through
rustdoc.
core: add a reverse method to Ordering.

This flips the comparison and is designed to be used when sorting etc.
rustdoc: Add rustdoc class to <body> tag

This allows for easier application of user stylesheets to rustdocs no
matter where they are hosted.
auto merge of #16191 : DaGenix/rust/fix-aligned-access, r=alexcrichton

When I originally wrote the read_u32v_be() and write_u32_be() functions, I didn't consider memory alignment requirements of various architectures. Unfortunately, the current implementations may result in unaligned reads and writes. This doesn't impact x86 / x86_64, but it can cause a compiler crash on ARM. This pull requests rewrites those functions to make sure that all memory access is always correctly aligned.

This fix is a little bit academic - due to the way that LLVM aligns the structures that are passed as arguments to these functions, I believe that the end result is that all memory access happens to be aligned anyway. However, there is nothing in that code that actually enforces that, at least not explicitly. The new implementations are definitely slower than the existing ones. However, I don't believe that these functions are all that significant when looking at the overall performance of the compiler. I think getting rid of some unsafe code and removing a potential portability landmine justifies a very slight decrease in raw performance.