Fix alignment tests for ARM on Linux. #14848
Add a split_at method to slice::ImmutableVector

This method is similar to the mut_split_at method of slice::MutableVector.
native: Fix utime() for windows

Apparently the units are in milliseconds, not in seconds!
Remove the "NFKC clause" in the reference manual.

The reference manual said that code is interpreted as UTF-8 text and a
implementation will normalize it to NFKC. However, rustc doesn't do
any normalization now.

We may want to do any normalization for symbols, but normalizing whole
text seems harmful because doing so loses some sort of information even
if we choose a non-K variant of normalization.

I'd suggest removing "normalized to Unicode normalization form NFKC"
phrase for the present so that the manual represents the current state
properly. When we address the problem (with a RFC?), then the manual
should be updated.

Closes #12388.

Reference: https://github.com/rust-lang/rust/issues/2253

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
Gedit/GTKSourceView: Add macro syntax highlighting.
Rename guessing_game.rs to main.rs in guide
docs: Fix typo in tutorial.
doc: Fix the 30-minute intro to use += operator.

The 30-minute intro had a comment mentioning that `+=` will be included in the future. It's already included, and this fixes it to use `+=`.
Clarify Argument docs.

Fixes #15830.
auto merge of #16179 : SimonPersson/rust/master, r=brson

This should solve issue 14848 for ARM.
auto merge of #16187 : steveklabnik/rust/gh15830, r=alexcrichton

Fixes #15830.
auto merge of #16188 : nham/rust/immut_slice_split_at, r=brson

This operation seems common enough that it would be convenient for it to be a standard method.
Fixes missing overflow lint for i64 #14269

The `type_overflow` lint, doesn't catch the overflow for `i64` because
the overflow happens earlier in the parse phase when the `u64` as biggest
possible int gets casted to `i64` , without checking the for overflows.
We can't lint in the parse phase, so a refactoring of the `LitInt` type
was necessary.

The types `LitInt`, `LitUint` and `LitIntUnsuffixed` where merged to one
type `LitInt` which stores it's value as `u64`. An additional parameter was
added which indicate the signedness of the type and the sign of the value.
auto merge of #16216 : omasanori/rust/nfkc, r=brson

The reference manual said that code is interpreted as UTF-8 text and a implementation will normalize it to NFKC. However, rustc doesn't do any normalization now.

We may want to do any normalization for symbols, but normalizing whole text seems harmful because doing so loses some sort of information even if we choose a non-K variant of normalization.

I'd suggest removing "normalized to Unicode normalization form NFKC" phrase for the present so that the manual represents the current state properly. When we address the problem (with a RFC?), then the manual should be updated.

Closes #12388.

Reference: https://github.com/rust-lang/rust/issues/2253
auto merge of #16231 : michaelsproul/rust/gedit-macro, r=alexcrichton

Gedit currently lacks syntax highlighting for macros.
auto merge of #16234 : cakebaker/rust/rename_guessing_game_rs_to_main_rs, r=steveklabnik

Follow-up to #16215
auto merge of #16243 : alexcrichton/rust/fix-utime-for-windows, r=brson

Apparently the units are in milliseconds, not in seconds!
auto merge of #16246 : ruud-v-a/rust/patch-1, r=brson
auto merge of #15709 : hirschenberger/rust/issue-14269, r=cmr

Fixes missing overflow lint for i64 #14269

The `type_overflow` lint, doesn't catch the overflow for `i64` because the overflow happens earlier in the parse phase when the `u64` as biggest possible int gets casted to `i64` , without checking the for
overflows.
We can't lint in the parse phase, so we emit a compiler error, as we do for overflowing `u64`

Perhaps a consistent behaviour would be to emit a parse error for *all*  overflowing integer types.

See #14269
auto merge of #16247 : TimDumol/rust/patch-1, r=alexcrichton

The 30-minute intro had a comment mentioning that `+=` will be included in the future. It's already included, and this fixes it to use `+=`.