Commit Graph

15 Commits

Author SHA1 Message Date
Wang Xuerui
2a41b31a88
syntax_ext: format: fix ICE with bad named arguments 2016-07-29 16:40:10 +08:00
Wang Xuerui
5e55a44116
syntax_ext: format: allow multiple formats for one argument
This commit removed the restriction of only allowing one type per argument.
This is achieved by adding mappings between macro arguments and format
placeholders, then taking the mapping into consideration when emitting
the Arguments expression.

syntax_ext: format: fix implicit positional arguments

syntax_ext: format: don't panic if no args given for implicit positional args

Check the list lengths before use.
Fixes regression of `compile-fail/macro-backtrace-println.rs`.

syntax_ext: format: also map CountIsParam indices to expanded args

syntax_ext: format: fix ICE in case of malformed format args
2016-07-14 03:10:45 +08:00
Jeffrey Seyfried
cc36e38279 Fix fallout in tests 2016-05-28 05:22:22 +00:00
Sean McArthur
44440e5c18 core: split into fmt::Show and fmt::String
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-06 14:49:42 -08:00
Alex Crichton
4af3494bb0 std: Stabilize std::fmt
This commit applies the stabilization of std::fmt as outlined in [RFC 380][rfc].
There are a number of breaking changes as a part of this commit which will need
to be handled to migrated old code:

* A number of formatting traits have been removed: String, Bool, Char, Unsigned,
  Signed, and Float. It is recommended to instead use Show wherever possible or
  to use adaptor structs to implement other methods of formatting.

* The format specifier for Boolean has changed from `t` to `b`.

* The enum `FormatError` has been renamed to `Error` as well as becoming a unit
  struct instead of an enum. The `WriteError` variant no longer exists.

* The `format_args_method!` macro has been removed with no replacement. Alter
  code to use the `format_args!` macro instead.

* The public fields of a `Formatter` have become read-only with no replacement.
  Use a new formatting string to alter the formatting flags in combination with
  the `write!` macro. The fields can be accessed through accessor methods on the
  `Formatter` structure.

Other than these breaking changes, the contents of std::fmt should now also all
contain stability markers. Most of them are still #[unstable] or #[experimental]

[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0380-stabilize-std-fmt.md
[breaking-change]

Closes #18904
2014-11-18 21:16:22 -08:00
Jonas Hietala
820a55857a Special case for 0 arguments given in format! 2014-07-18 20:39:38 +02:00
Jonas Hietala
18717fcf68 Correct plural of arguments in format_args! 2014-07-18 19:25:46 +02:00
Alex Crichton
cac7a2053a std: Remove i18n/l10n from format!
* The select/plural methods from format strings are removed
* The # character no longer needs to be escaped
* The \-based escapes have been removed
* '{{' is now an escape for '{'
* '}}' is now an escape for '}'

Closes #14810
[breaking-change]
2014-06-11 16:04:24 -07:00
Alex Crichton
a447c3ca16 Try to improve format! error messages
Instead of just saying "unterminated format string" and friends, instead print
information about what was expected and what was found.

Closes #9931
2013-10-18 21:28:00 -07:00
Alex Crichton
b74663e027 Remove the notion of an "unknown format"
As mentioned in #9456, the format! syntax extension would previously consider an
empty format as a 'Unknown' format which could then also get coerced into a
different style of format on another argument.

This is unusual behavior because `{}` is a very common format and if you have
`{0} {0:?}` you wouldn't expect them both to be coereced to the `Poly`
formatter. This commit removes this coercion, but still retains the requirement
that each argument has exactly one format specified for it (an empty format now
counts as well).

Perhaps at a later date we can add support for multiple formats of one argument,
but this puts us in at least a backwards-compatible situation if we decide to do
that.
2013-09-27 09:39:05 -07:00
Alex Crichton
fd8c05ccc9 Document all of the format! related macros 2013-09-15 01:09:00 -07:00
Alex Crichton
cfe3db810b Reduce the amount of complexity in format!
This renames the syntax-extension file to format from ifmt, and it also reduces
the amount of complexity inside by defining all other macros in terms of
format_args!
2013-09-15 01:09:00 -07:00
Alex Crichton
ba1f663bbd Raise errors on format strings with unmatched }
Otherwise extra stuff after a lone '}' character is simply ignored, which is
very bad.

Closes #8938
2013-09-03 23:02:59 -07:00
Alex Crichton
eb836dd61e Settle on the format/write/print family of names 2013-08-24 12:48:10 -07:00
Alex Crichton
ffb670ffcd Add initial support for a new formatting syntax
The new macro is available under the name ifmt! (only an intermediate name)
2013-08-07 19:21:43 -07:00