about summary refs log tree commit diff
path: root/src/test/run-pass/ifmt.rs
AgeCommit message (Collapse)AuthorLines
2019-07-27tests: Move run-pass tests without naming conflicts to uiVadim Petrochenkov-323/+0
2019-07-27tests: Add missing run-pass annotationsVadim Petrochenkov-0/+2
2019-05-29Update run-pass test suite to use dynmemoryruins-1/+1
2019-03-30Fix more testsFabian Drinck-2/+0
2018-12-25Remove licensesMark Rousskov-10/+0
2018-08-19Fix typos found by codespell.Matthias Krüger-1/+1
2017-12-19Always print floats with a decimal point with the Debug formatterDiggory Blake-2/+2
2017-09-21Less confusing placeholder when RefCell is exclusively borrowedDavid Tolnay-0/+12
Based on ExpHP's comment in https://users.rust-lang.org/t/refcell-borrow-mut-get-strange-result/12994 > it would perhaps be nicer if it didn't put something that could be > misinterpreted as a valid string value The previous Debug implementation would show: RefCell { value: "<borrowed>" } The new one is: RefCell { value: <borrowed> }
2017-03-15Change how the 0 flag works in format! for floatsPiotr Jawniak-0/+12
Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`. :06 :<06 :>06 :^06 before |-001.2| |-1.200| |-001.2| |-01.20| after |-001.2| |-001.2| |-001.2| |-001.2|
2017-03-15Change how the `0` flag works in format!Piotr Jawniak-0/+16
Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`. This also affects the '#' flag: zeroes are placed after the prefix (0b, 0o, 0x) and before the digits. :05 :<05 :>05 :^05 before |-0001| |-1000| |-0001| |-0100| after |-0001| |-0001| |-0001| |-0001| :#05x :<#05x :>#05x :^#05x before |0x001| |0x100| |000x1| |0x010| after |0x001| |0x001| |0x001| |0x001| Fixes #39997 [breaking-change]
2016-10-31Changed most vec! invocations to use square bracesiirelu-1/+1
Most of the Rust community agrees that the vec! macro is clearer when called using square brackets [] instead of regular brackets (). Most of these ocurrences are from before macros allowed using different types of brackets. There is one left unchanged in a pretty-print test, as the pretty printer still wants it to have regular brackets.
2016-10-18Fix some pretty printing testsVadim Petrochenkov-2/+0
2016-10-12Stabilise `?`Nick Cameron-1/+0
cc [`?` tracking issue](https://github.com/rust-lang/rust/issues/31436)
2016-07-23Fix run-pass/ifmt testTobias Bucher-3/+3
2016-07-21Auto merge of #34544 - ↵bors-1/+2
3Hren:issue/xx/reinterpret-format-precision-for-strings, r=alexcrichton 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.
2016-07-14format: add tests for ergonomic format_args!Wang Xuerui-0/+33
format: workaround pretty-printer to pass tests
2016-07-06feat: reinterpret `precision` field for stringsEvgeny Safronov-1/+2
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 <division494@gmail.com>
2016-03-23Make warnings of renamed and removed lints themselves lintsBrian Anderson-1/+1
This adds the `renamed_and_removed_lints` warning, defaulting to the warning level. Fixes #31141
2016-03-22sprinkle feature gates here and thereJorge Aparicio-0/+1
2016-03-22try! -> ?Jorge Aparicio-2/+2
Automated conversion using the untry tool [1] and the following command: ``` $ find -name '*.rs' -type f | xargs untry ``` at the root of the Rust repo. [1]: https://github.com/japaric/untry
2015-09-29Add `fmt::Debug` string escape testsSimon Mazur-0/+4
2015-06-10Have std::fmt::Formatter implement std::fmt::Write.Simon Sapin-1/+1
2015-06-10Add a write_char method to std::fmt::Formatter.Simon Sapin-0/+9
This is the logical next step after #24661, but I’m less sure about this one.
2015-04-23Rollup merge of #24688 - SimonSapin:fmt-write-char, r=alexcrichtonManish Goregaokar-1/+3
… added in #24661.
2015-04-22Add a test for std::fmt::Write::write_charSimon Sapin-1/+3
2015-04-21Model lexer: Fix remaining issuesPiotr Czarnecki-1/+0
2015-04-12Make Debug include the - in -0.0Robin Kruppe-1/+7
2015-04-09fmt: Assume that we'll only ever see 32 or 64 bit pointersRicho Healey-2/+1
2015-04-09test: Unignore test for fixed issue #20676Richo Healey-3/+2
2015-04-09fmt: {:p#} formats pointers padded to native widthRicho Healey-0/+8
2015-03-03Add `: Box<_>` or `::Box<_>` type annotations to various places.Felix S. Klock II-1/+1
This is the kind of change that one is expected to need to make to accommodate overloaded-`box`. ---- Note that this is not *all* of the changes necessary to accommodate Issue 22181. It is merely the subset of those cases where there was already a let-binding in place that made it easy to add the necesasry type ascription. (For unnamed intermediate `Box` values, one must go down a different route; `Box::new` is the option that maximizes portability, but has potential inefficiency depending on whether the call is inlined.) ---- There is one place worth note, `run-pass/coerce-match.rs`, where I used an ugly form of `Box<_>` type ascription where I would have preferred to use `Box::new` to accommodate overloaded-`box`. I deliberately did not use `Box::new` here, because that is already done in coerce-match-calls.rs. ---- Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
2015-03-01Add import of usize (fixup #22901)Manish Goregaokar-0/+1
2015-02-28ifmt - Add a basic test for {:p} getting truncatedJohn Hodge-0/+7
2015-02-18Update suffixes en masse in tests using `perl -p -i -e`Niko Matsakis-6/+6
2015-02-14Rename `fmt::Writer` to `fmt::Write`Chris Wong-3/+3
This brings it in line with its namesake in `std::io`. [breaking-change]
2015-02-05cleanup: replace `as[_mut]_slice()` calls with deref coercionsJorge Aparicio-1/+1
2015-01-31Kill more `isize`sTobias Bucher-2/+2
2015-01-30Remove all `i` suffixesTobias Bucher-12/+12
2015-01-25Merge remote-tracking branch 'rust-lang/master'Brian Anderson-12/+12
Conflicts: mk/tests.mk src/liballoc/arc.rs src/liballoc/boxed.rs src/liballoc/rc.rs src/libcollections/bit.rs src/libcollections/btree/map.rs src/libcollections/btree/set.rs src/libcollections/dlist.rs src/libcollections/ring_buf.rs src/libcollections/slice.rs src/libcollections/str.rs src/libcollections/string.rs src/libcollections/vec.rs src/libcollections/vec_map.rs src/libcore/any.rs src/libcore/array.rs src/libcore/borrow.rs src/libcore/error.rs src/libcore/fmt/mod.rs src/libcore/iter.rs src/libcore/marker.rs src/libcore/ops.rs src/libcore/result.rs src/libcore/slice.rs src/libcore/str/mod.rs src/libregex/lib.rs src/libregex/re.rs src/librustc/lint/builtin.rs src/libstd/collections/hash/map.rs src/libstd/collections/hash/set.rs src/libstd/sync/mpsc/mod.rs src/libstd/sync/mutex.rs src/libstd/sync/poison.rs src/libstd/sync/rwlock.rs src/libsyntax/feature_gate.rs src/libsyntax/test.rs
2015-01-21Tie stability attributes to feature gatesBrian Anderson-1/+0
2015-01-20std: Rename Show/String to Debug/DisplayAlex Crichton-12/+12
This commit is an implementation of [RFC 565][rfc] which is a stabilization of the `std::fmt` module and the implementations of various formatting traits. Specifically, the following changes were performed: [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md * The `Show` trait is now deprecated, it was renamed to `Debug` * The `String` trait is now deprecated, it was renamed to `Display` * Many `Debug` and `Display` implementations were audited in accordance with the RFC and audited implementations now have the `#[stable]` attribute * Integers and floats no longer print a suffix * Smart pointers no longer print details that they are a smart pointer * Paths with `Debug` are now quoted and escape characters * The `unwrap` methods on `Result` now require `Display` instead of `Debug` * The `Error` trait no longer has a `detail` method and now requires that `Display` must be implemented. With the loss of `String`, this has moved into libcore. * `impl<E: Error> FromError<E> for Box<Error>` now exists * `derive(Show)` has been renamed to `derive(Debug)`. This is not currently warned about due to warnings being emitted on stage1+ While backwards compatibility is attempted to be maintained with a blanket implementation of `Display` for the old `String` trait (and the same for `Show`/`Debug`) this is still a breaking change due to primitives no longer implementing `String` as well as modifications such as `unwrap` and the `Error` trait. Most code is fairly straightforward to update with a rename or tweaks of method calls. [breaking-change] Closes #21436
2015-01-17Add allow(unstable) to more testsBrian Anderson-0/+1
2015-01-07rollup merge of #20723: pnkfelix/feature-gate-box-syntaxAlex Crichton-0/+2
Conflicts: src/compiletest/compiletest.rs src/libcollections/lib.rs src/libserialize/lib.rs src/libsyntax/feature_gate.rs
2015-01-08fallout: run-pass tests that use box. (many could be ported to `Box::new` ↵Felix S. Klock II-0/+2
instead in the future.)
2015-01-07std: Tweak String implementationsAlex Crichton-1/+1
This commit performs a pass over the implementations of the new `String` trait in the formatting module. Some implementations were removed as a conservative move pending an upcoming convention about `String` implementations, and some were added in order to retain consistency across the libraries. Specifically: * All "smart pointers" implement `String` now, adding missing implementations for `Arc` and `Rc`. * The `Vec<T>` and `[T]` types no longer implement `String`. * The `*const T` and `*mut T` type no longer implement `String`. * The `()` type no longer implements `String`. * The `Path` type's `Show` implementation does not surround itself with `Path {}` (a minor tweak). All implementations of `String` in this PR were also marked `#[stable]` to indicate that the types will continue to implement the `String` trait regardless of what it looks like.
2015-01-06More test fixesAlex Crichton-2/+3
2015-01-06core: split into fmt::Show and fmt::StringSean McArthur-4/+8
fmt::Show is for debugging, and can and should be implemented for all public types. This trait is used with `{:?}` syntax. There still exists #[derive(Show)]. fmt::String is for types that faithfully be represented as a String. Because of this, there is no way to derive fmt::String, all implementations must be purposeful. It is used by the default format syntax, `{}`. This will break most instances of `{}`, since that now requires the type to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the correct fix. Types that were being printed specifically for users should receive a fmt::String implementation to fix this. Part of #20013 [breaking-change]
2015-01-05Un-gate macro_rulesKeegan McAllister-1/+0
2015-01-05Modernize macro_rules! invocationsKeegan McAllister-1/+3
macro_rules! is like an item that defines a macro. Other items don't have a trailing semicolon, or use a paren-delimited body. If there's an argument for matching the invocation syntax, e.g. parentheses for an expr macro, then I think that applies more strongly to the *inner* delimiters on the LHS, wrapping the individual argument patterns.
2015-01-01std: Enforce Unicode in fmt::WriterAlex Crichton-12/+12
This commit is an implementation of [RFC 526][rfc] which is a change to alter the definition of the old `fmt::FormatWriter`. The new trait, renamed to `Writer`, now only exposes one method `write_str` in order to guarantee that all implementations of the formatting traits can only produce valid Unicode. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md One of the primary improvements of this patch is the performance of the `.to_string()` method by avoiding an almost-always redundant UTF-8 check. This is a breaking change due to the renaming of the trait as well as the loss of the `write` method, but migration paths should be relatively easy: * All usage of `write` should move to `write_str`. If truly binary data was being written in an implementation of `Show`, then it will need to use a different trait or an altogether different code path. * All usage of `write!` should continue to work as-is with no modifications. * All usage of `Show` where implementations just delegate to another should continue to work as-is. [breaking-change] Closes #20352
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 23:45:19 +0000