rust/src/libcore/fmt, branch 1.12.1

Rename empty/bang to never

2016-08-13T13:37:09+00:00

Split Ty::is_empty method into is_never and is_uninhabited

Minor fixups based on @eddyb's feedback

2016-08-13T13:37:09+00:00

Mainly, remove mk_empty() method and replace with tcx.types.empty

impl Debug + Display for !

2016-08-13T13:37:09+00:00

Rename `char::escape` to `char::escape_debug` and add tracking issue

2016-07-28T00:20:49+00:00

Restore `char::escape_default` and add `char::escape` instead

2016-07-26T13:15:00+00:00

Auto merge of #34544 - 3Hren:issue/xx/reinterpret-format-precision-for-strings, r=alexcrichton

2016-07-21T23:19:54+00:00

feat: reinterpret `precision` field for strings This commit changes the behavior of formatting string arguments with both width and precision fields set. Documentation says that the `width` field is the "minimum width" that the format should take up. If the value's string does not fill up this many characters, then the padding specified by fill/alignment will be used to take up the required space. This is true for all formatted types except string, which is truncated down to `precision` number of chars and then all of `fill`, `align` and `width` fields are completely ignored. For example: `format!("{:/^10.8}", "1234567890);` emits "12345678". In the contrast Python version works as the expected: ```python >>> '{:/^10.8}'.format('1234567890') '/12345678/' ``` This commit gives back the `Python` behavior by changing the `precision` field meaning to the truncation and nothing more. The result string *will* be prepended/appended up to the `width` field with the proper `fill` char. __However, this is the breaking change, I admit.__ Feel free to close it, but otherwise it should be mentioned in the `std::fmt` documentation somewhere near of `fill/align/width` fields description.

feat: reinterpret `precision` field for strings

2016-07-05T21:01:14+00:00

This commit changes the behavior of formatting string arguments with both width and precision fields set. Documentation says that the `width` field is the "minimum width" that the format should take up. If the value's string does not fill up this many characters, then the padding specified by fill/alignment will be used to take up the required space. This is true for all formatted types except string, which is truncated down to `precision` number of chars and then all of `fill`, `align` and `width` fields are completely ignored. For example: `format!("{:/^10.8}", "1234567890);` emits "12345678". In the contrast Python version works as the expected: ```python >>> '{:/^10.8}'.format('1234567890') '/12345678/' ``` This commit gives back the `Python` behavior by changing the `precision` field meaning to the truncation and nothing more. The result string *will* be prepended/appended up to the `width` field with the proper `fill` char. However, this is the breaking change. Also updated `std::fmt` docs about string precision. Signed-off-by: Evgeny Safronov

prefer `if let` to match with `None => {}` arm in some places

2016-07-03T23:27:02+00:00

This is a spiritual succesor to #34268/8531d581, in which we replaced a number of matches of None to the unit value with `if let` conditionals where it was judged that this made for clearer/simpler code (as would be recommended by Manishearth/rust-clippy's `single_match` lint). The same rationale applies to matches of None to the empty block.

Use `len` instead of `size_hint` where appropiate

2016-06-23T10:26:15+00:00

This makes it clearer that we're not just looking for a lower bound but rather know that the iterator is an `ExactSizeIterator`.

Auto merge of #33460 - shepmaster:16-bit-pointers, r=Aatch

2016-06-04T05:32:15+00:00

Support 16-bit pointers as well as i/usize I'm opening this pull request to get some feedback from the community. Although Rust doesn't support any platforms with a native 16-bit pointer at the moment, the [AVR-Rust][ar] fork is working towards that goal. Keeping this forked logic up-to-date with the changes in master has been onerous so I'd like to merge these changes so that they get carried along when refactoring happens. I do not believe this should increase the maintenance burden. This is based on the original work of Dylan McKay (@dylanmckay). [ar]: https://github.com/avr-rust/rust