2013-07-29 01:12:41 -07:00
|
|
|
// Copyright 2012 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2014-11-06 00:05:53 -08:00
|
|
|
use self::ArgumentType::*;
|
|
|
|
use self::Position::*;
|
|
|
|
|
2014-08-18 08:29:44 -07:00
|
|
|
use fmt_macros as parse;
|
2015-12-10 23:23:14 +09:00
|
|
|
|
|
|
|
use syntax::ast;
|
|
|
|
use syntax::ext::base::*;
|
|
|
|
use syntax::ext::base;
|
|
|
|
use syntax::ext::build::AstBuilder;
|
2016-11-16 08:21:52 +00:00
|
|
|
use syntax::parse::token;
|
2015-12-10 23:23:14 +09:00
|
|
|
use syntax::ptr::P;
|
2017-09-04 13:23:49 +03:00
|
|
|
use syntax::symbol::Symbol;
|
2017-07-28 16:42:39 +12:00
|
|
|
use syntax_pos::{Span, DUMMY_SP};
|
2016-06-20 08:49:33 -07:00
|
|
|
use syntax::tokenstream;
|
2014-02-19 19:29:58 -08:00
|
|
|
|
2016-11-11 15:23:15 +11:00
|
|
|
use std::collections::{HashMap, HashSet};
|
2016-05-21 16:00:01 +08:00
|
|
|
use std::collections::hash_map::Entry;
|
2013-07-29 01:12:41 -07:00
|
|
|
|
2015-01-03 22:54:18 -05:00
|
|
|
#[derive(PartialEq)]
|
2013-07-29 01:12:41 -07:00
|
|
|
enum ArgumentType {
|
2016-05-21 12:58:17 +08:00
|
|
|
Placeholder(String),
|
|
|
|
Count,
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
|
2013-12-25 21:55:05 -08:00
|
|
|
enum Position {
|
2015-01-17 23:33:05 +00:00
|
|
|
Exact(usize),
|
2014-12-20 23:37:25 +02:00
|
|
|
Named(String),
|
2013-12-25 21:55:05 -08:00
|
|
|
}
|
|
|
|
|
2016-06-06 20:22:48 +05:30
|
|
|
struct Context<'a, 'b: 'a> {
|
2014-03-09 16:54:34 +02:00
|
|
|
ecx: &'a mut ExtCtxt<'b>,
|
2015-04-10 04:11:21 -07:00
|
|
|
/// The macro's call site. References to unstable formatting internals must
|
|
|
|
/// use this span to pass the stability checker.
|
|
|
|
macsp: Span,
|
|
|
|
/// The span of the format string literal.
|
2013-08-31 18:13:04 +02:00
|
|
|
fmtsp: Span,
|
2013-07-29 01:12:41 -07:00
|
|
|
|
2016-06-02 21:47:34 +08:00
|
|
|
/// List of parsed argument expressions.
|
2016-06-05 20:39:05 +08:00
|
|
|
/// Named expressions are resolved early, and are appended to the end of
|
|
|
|
/// argument expressions.
|
2016-06-02 21:47:34 +08:00
|
|
|
///
|
|
|
|
/// Example showing the various data structures in motion:
|
|
|
|
///
|
|
|
|
/// * Original: `"{foo:o} {:o} {foo:x} {0:x} {1:o} {:x} {1:x} {0:o}"`
|
|
|
|
/// * Implicit argument resolution: `"{foo:o} {0:o} {foo:x} {0:x} {1:o} {1:x} {1:x} {0:o}"`
|
|
|
|
/// * Name resolution: `"{2:o} {0:o} {2:x} {0:x} {1:o} {1:x} {1:x} {0:o}"`
|
|
|
|
/// * `arg_types` (in JSON): `[[0, 1, 0], [0, 1, 1], [0, 1]]`
|
|
|
|
/// * `arg_unique_types` (in simplified JSON): `[["o", "x"], ["o", "x"], ["o", "x"]]`
|
|
|
|
/// * `names` (in JSON): `{"foo": 2}`
|
2014-09-13 19:06:01 +03:00
|
|
|
args: Vec<P<ast::Expr>>,
|
2016-06-02 21:47:34 +08:00
|
|
|
/// Placeholder slot numbers indexed by argument.
|
2016-06-02 18:16:24 +08:00
|
|
|
arg_types: Vec<Vec<usize>>,
|
2016-06-02 21:47:34 +08:00
|
|
|
/// Unique format specs seen for each argument.
|
2016-06-02 18:16:24 +08:00
|
|
|
arg_unique_types: Vec<Vec<ArgumentType>>,
|
2016-06-05 20:39:05 +08:00
|
|
|
/// Map from named arguments to their resolved indices.
|
|
|
|
names: HashMap<String, usize>,
|
2013-07-29 01:12:41 -07:00
|
|
|
|
2014-08-21 14:34:00 +01:00
|
|
|
/// The latest consecutive literal strings, or empty if there weren't any.
|
2014-12-20 23:37:25 +02:00
|
|
|
literal: String,
|
2014-07-20 16:31:43 +02:00
|
|
|
|
2014-08-21 14:34:00 +01:00
|
|
|
/// Collection of the compiled `rt::Argument` structures
|
2014-09-13 19:06:01 +03:00
|
|
|
pieces: Vec<P<ast::Expr>>,
|
2014-08-21 14:34:00 +01:00
|
|
|
/// Collection of string literals
|
2014-09-13 19:06:01 +03:00
|
|
|
str_pieces: Vec<P<ast::Expr>>,
|
2014-08-25 14:26:18 +01:00
|
|
|
/// Stays `true` if all formatting parameters are default (as in "{}{}").
|
|
|
|
all_pieces_simple: bool,
|
|
|
|
|
2016-05-14 20:42:47 +08:00
|
|
|
/// Mapping between positional argument references and indices into the
|
|
|
|
/// final generated static argument array. We record the starting indices
|
|
|
|
/// corresponding to each positional argument, and number of references
|
|
|
|
/// consumed so far for each argument, to facilitate correct `Position`
|
2018-05-08 16:10:16 +03:00
|
|
|
/// mapping in `build_piece`. In effect this can be seen as a "flattened"
|
2016-06-02 21:47:34 +08:00
|
|
|
/// version of `arg_unique_types`.
|
|
|
|
///
|
|
|
|
/// Again with the example described above in docstring for `args`:
|
|
|
|
///
|
|
|
|
/// * `arg_index_map` (in JSON): `[[0, 1, 0], [2, 3, 3], [4, 5]]`
|
2016-06-02 18:16:24 +08:00
|
|
|
arg_index_map: Vec<Vec<usize>>,
|
2016-05-14 20:42:47 +08:00
|
|
|
|
2016-06-02 21:47:34 +08:00
|
|
|
/// Starting offset of count argument slots.
|
2016-05-21 16:00:01 +08:00
|
|
|
count_args_index_offset: usize,
|
|
|
|
|
2016-06-02 21:47:34 +08:00
|
|
|
/// Count argument slots and tracking data structures.
|
|
|
|
/// Count arguments are separately tracked for de-duplication in case
|
|
|
|
/// multiple references are made to one argument. For example, in this
|
|
|
|
/// format string:
|
|
|
|
///
|
|
|
|
/// * Original: `"{:.*} {:.foo$} {1:.*} {:.0$}"`
|
|
|
|
/// * Implicit argument resolution: `"{1:.0$} {2:.foo$} {1:.3$} {4:.0$}"`
|
|
|
|
/// * Name resolution: `"{1:.0$} {2:.5$} {1:.3$} {4:.0$}"`
|
|
|
|
/// * `count_positions` (in JSON): `{0: 0, 5: 1, 3: 2}`
|
|
|
|
/// * `count_args`: `vec![Exact(0), Exact(5), Exact(3)]`
|
2016-05-21 16:00:01 +08:00
|
|
|
count_args: Vec<Position>,
|
2016-06-02 21:47:34 +08:00
|
|
|
/// Relative slot numbers for count arguments.
|
2016-05-21 16:00:01 +08:00
|
|
|
count_positions: HashMap<usize, usize>,
|
2016-06-02 21:47:34 +08:00
|
|
|
/// Number of count slots assigned.
|
2016-05-21 16:00:01 +08:00
|
|
|
count_positions_count: usize,
|
|
|
|
|
2016-05-17 01:02:42 +08:00
|
|
|
/// Current position of the implicit positional arg pointer, as if it
|
|
|
|
/// still existed in this phase of processing.
|
2018-05-08 16:10:16 +03:00
|
|
|
/// Used only for `all_pieces_simple` tracking in `build_piece`.
|
2016-05-17 01:02:42 +08:00
|
|
|
curarg: usize,
|
2017-11-06 08:49:47 +00:00
|
|
|
/// Keep track of invalid references to positional arguments
|
|
|
|
invalid_refs: Vec<usize>,
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
|
2014-02-06 08:50:36 +11:00
|
|
|
/// Parses the arguments from the given list of tokens, returning None
|
|
|
|
/// if there's a parse error so we can continue parsing other format!
|
|
|
|
/// expressions.
|
|
|
|
///
|
2014-12-21 11:28:18 +02:00
|
|
|
/// If parsing succeeds, the return value is:
|
2017-06-20 15:15:16 +08:00
|
|
|
///
|
|
|
|
/// ```text
|
2016-06-05 20:39:05 +08:00
|
|
|
/// Some((fmtstr, parsed arguments, index map for named arguments))
|
2015-11-03 16:34:11 +00:00
|
|
|
/// ```
|
2016-06-06 20:22:48 +05:30
|
|
|
fn parse_args(ecx: &mut ExtCtxt,
|
|
|
|
sp: Span,
|
|
|
|
tts: &[tokenstream::TokenTree])
|
2016-06-05 20:39:05 +08:00
|
|
|
-> Option<(P<ast::Expr>, Vec<P<ast::Expr>>, HashMap<String, usize>)> {
|
|
|
|
let mut args = Vec::<P<ast::Expr>>::new();
|
|
|
|
let mut names = HashMap::<String, usize>::new();
|
2014-02-06 08:50:36 +11:00
|
|
|
|
2014-07-03 11:42:24 +02:00
|
|
|
let mut p = ecx.new_parser_from_tts(tts);
|
2013-08-20 00:40:27 -07:00
|
|
|
|
2014-10-27 19:22:52 +11:00
|
|
|
if p.token == token::Eof {
|
2014-02-06 08:50:36 +11:00
|
|
|
ecx.span_err(sp, "requires at least a format string argument");
|
2014-12-21 11:28:18 +02:00
|
|
|
return None;
|
2014-02-06 08:50:36 +11:00
|
|
|
}
|
2015-11-10 16:08:26 -08:00
|
|
|
let fmtstr = panictry!(p.parse_expr());
|
2014-02-06 08:50:36 +11:00
|
|
|
let mut named = false;
|
2014-10-27 19:22:52 +11:00
|
|
|
while p.token != token::Eof {
|
2015-12-31 12:11:53 +13:00
|
|
|
if !p.eat(&token::Comma) {
|
2014-02-06 08:50:36 +11:00
|
|
|
ecx.span_err(sp, "expected token: `,`");
|
2014-12-21 11:28:18 +02:00
|
|
|
return None;
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
2016-06-06 20:22:48 +05:30
|
|
|
if p.token == token::Eof {
|
|
|
|
break;
|
|
|
|
} // accept trailing commas
|
2014-10-27 23:33:30 +11:00
|
|
|
if named || (p.token.is_ident() && p.look_ahead(1, |t| *t == token::Eq)) {
|
2014-02-06 08:50:36 +11:00
|
|
|
named = true;
|
|
|
|
let ident = match p.token {
|
2018-03-09 23:56:40 -06:00
|
|
|
token::Ident(i, _) => {
|
2015-12-31 12:11:53 +13:00
|
|
|
p.bump();
|
2014-02-06 08:50:36 +11:00
|
|
|
i
|
|
|
|
}
|
|
|
|
_ if named => {
|
|
|
|
ecx.span_err(p.span,
|
|
|
|
"expected ident, positional arguments \
|
|
|
|
cannot follow named arguments");
|
2014-12-21 11:28:18 +02:00
|
|
|
return None;
|
2014-02-06 08:50:36 +11:00
|
|
|
}
|
|
|
|
_ => {
|
|
|
|
ecx.span_err(p.span,
|
2015-01-07 11:58:31 -05:00
|
|
|
&format!("expected ident for named argument, found `{}`",
|
2016-06-06 20:22:48 +05:30
|
|
|
p.this_token_to_string()));
|
2014-12-21 11:28:18 +02:00
|
|
|
return None;
|
2014-02-06 08:50:36 +11:00
|
|
|
}
|
|
|
|
};
|
2018-05-26 15:12:38 +03:00
|
|
|
let name: &str = &ident.as_str();
|
2015-02-03 23:31:06 +01:00
|
|
|
|
2015-03-28 21:58:51 +00:00
|
|
|
panictry!(p.expect(&token::Eq));
|
2015-11-10 16:08:26 -08:00
|
|
|
let e = panictry!(p.parse_expr());
|
2016-07-03 14:38:37 -07:00
|
|
|
if let Some(prev) = names.get(name) {
|
2016-06-06 20:22:48 +05:30
|
|
|
ecx.struct_span_err(e.span, &format!("duplicate argument named `{}`", name))
|
2016-06-05 20:39:05 +08:00
|
|
|
.span_note(args[*prev].span, "previously here")
|
2016-07-03 14:38:37 -07:00
|
|
|
.emit();
|
|
|
|
continue;
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
2016-06-05 20:39:05 +08:00
|
|
|
|
|
|
|
// Resolve names into slots early.
|
|
|
|
// Since all the positional args are already seen at this point
|
|
|
|
// if the input is valid, we can simply append to the positional
|
|
|
|
// args. And remember the names.
|
|
|
|
let slot = args.len();
|
|
|
|
names.insert(name.to_string(), slot);
|
|
|
|
args.push(e);
|
2014-02-06 08:50:36 +11:00
|
|
|
} else {
|
2015-11-10 16:08:26 -08:00
|
|
|
args.push(panictry!(p.parse_expr()));
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
}
|
2016-06-05 20:39:05 +08:00
|
|
|
Some((fmtstr, args, names))
|
2014-02-06 08:50:36 +11:00
|
|
|
}
|
2013-07-29 01:12:41 -07:00
|
|
|
|
2014-03-09 16:54:34 +02:00
|
|
|
impl<'a, 'b> Context<'a, 'b> {
|
2016-06-05 20:39:05 +08:00
|
|
|
fn resolve_name_inplace(&self, p: &mut parse::Piece) {
|
2016-06-02 21:47:34 +08:00
|
|
|
// NOTE: the `unwrap_or` branch is needed in case of invalid format
|
|
|
|
// arguments, e.g. `format_args!("{foo}")`.
|
2016-06-05 20:39:05 +08:00
|
|
|
let lookup = |s| *self.names.get(s).unwrap_or(&0);
|
|
|
|
|
|
|
|
match *p {
|
|
|
|
parse::String(_) => {}
|
|
|
|
parse::NextArgument(ref mut arg) => {
|
|
|
|
if let parse::ArgumentNamed(s) = arg.position {
|
|
|
|
arg.position = parse::ArgumentIs(lookup(s));
|
|
|
|
}
|
|
|
|
if let parse::CountIsName(s) = arg.format.width {
|
|
|
|
arg.format.width = parse::CountIsParam(lookup(s));
|
|
|
|
}
|
|
|
|
if let parse::CountIsName(s) = arg.format.precision {
|
|
|
|
arg.format.precision = parse::CountIsParam(lookup(s));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-02 21:47:34 +08:00
|
|
|
/// Verifies one piece of a parse string, and remembers it if valid.
|
|
|
|
/// All errors are not emitted as fatal so we can continue giving errors
|
|
|
|
/// about this and possibly other format strings.
|
2013-07-29 01:12:41 -07:00
|
|
|
fn verify_piece(&mut self, p: &parse::Piece) {
|
|
|
|
match *p {
|
2013-11-28 12:22:53 -08:00
|
|
|
parse::String(..) => {}
|
2014-09-11 17:07:49 +12:00
|
|
|
parse::NextArgument(ref arg) => {
|
2013-08-10 00:28:47 -07:00
|
|
|
// width/precision first, if they have implicit positional
|
|
|
|
// parameters it makes more sense to consume them first.
|
|
|
|
self.verify_count(arg.format.width);
|
|
|
|
self.verify_count(arg.format.precision);
|
|
|
|
|
|
|
|
// argument second, if it's an implicit positional parameter
|
|
|
|
// it's written second, so it should come after width/precision.
|
2013-07-29 01:12:41 -07:00
|
|
|
let pos = match arg.position {
|
2017-11-09 17:16:25 +00:00
|
|
|
parse::ArgumentIs(i) | parse::ArgumentImplicitlyIs(i) => Exact(i),
|
2014-05-25 03:17:19 -07:00
|
|
|
parse::ArgumentNamed(s) => Named(s.to_string()),
|
2013-07-29 01:12:41 -07:00
|
|
|
};
|
|
|
|
|
2016-05-21 12:58:17 +08:00
|
|
|
let ty = Placeholder(arg.format.ty.to_string());
|
2014-05-28 09:24:28 -07:00
|
|
|
self.verify_arg_type(pos, ty);
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn verify_count(&mut self, c: parse::Count) {
|
|
|
|
match c {
|
2016-06-06 20:22:48 +05:30
|
|
|
parse::CountImplied |
|
|
|
|
parse::CountIs(..) => {}
|
2013-07-29 01:12:41 -07:00
|
|
|
parse::CountIsParam(i) => {
|
2016-05-21 12:58:17 +08:00
|
|
|
self.verify_arg_type(Exact(i), Count);
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
2013-10-12 20:00:58 -07:00
|
|
|
parse::CountIsName(s) => {
|
2016-05-21 12:58:17 +08:00
|
|
|
self.verify_arg_type(Named(s.to_string()), Count);
|
2013-10-12 20:00:58 -07:00
|
|
|
}
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-20 23:37:25 +02:00
|
|
|
fn describe_num_args(&self) -> String {
|
2014-07-18 20:39:38 +02:00
|
|
|
match self.args.len() {
|
2017-11-06 08:49:47 +00:00
|
|
|
0 => "no arguments were given".to_string(),
|
2017-11-09 17:16:25 +00:00
|
|
|
1 => "there is 1 argument".to_string(),
|
|
|
|
x => format!("there are {} arguments", x),
|
2014-07-18 18:34:49 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-06 08:49:47 +00:00
|
|
|
/// Handle invalid references to positional arguments. Output different
|
|
|
|
/// errors for the case where all arguments are positional and for when
|
2017-11-09 17:16:25 +00:00
|
|
|
/// there are named arguments or numbered positional arguments in the
|
|
|
|
/// format string.
|
|
|
|
fn report_invalid_references(&self, numbered_position_args: bool) {
|
|
|
|
let mut e;
|
2017-11-06 08:49:47 +00:00
|
|
|
let mut refs: Vec<String> = self.invalid_refs
|
|
|
|
.iter()
|
|
|
|
.map(|r| r.to_string())
|
|
|
|
.collect();
|
|
|
|
|
2017-11-09 17:16:25 +00:00
|
|
|
if self.names.is_empty() && !numbered_position_args {
|
|
|
|
e = self.ecx.mut_span_err(self.fmtsp,
|
|
|
|
&format!("{} positional argument{} in format string, but {}",
|
|
|
|
self.pieces.len(),
|
|
|
|
if self.pieces.len() > 1 { "s" } else { "" },
|
|
|
|
self.describe_num_args()));
|
2017-11-06 08:49:47 +00:00
|
|
|
} else {
|
|
|
|
let arg_list = match refs.len() {
|
|
|
|
1 => format!("argument {}", refs.pop().unwrap()),
|
|
|
|
_ => format!("arguments {head} and {tail}",
|
|
|
|
tail=refs.pop().unwrap(),
|
|
|
|
head=refs.join(", "))
|
|
|
|
};
|
|
|
|
|
2017-11-09 17:16:25 +00:00
|
|
|
e = self.ecx.mut_span_err(self.fmtsp,
|
|
|
|
&format!("invalid reference to positional {} ({})",
|
|
|
|
arg_list,
|
|
|
|
self.describe_num_args()));
|
|
|
|
e.note("positional arguments are zero-based");
|
2017-11-06 08:49:47 +00:00
|
|
|
};
|
|
|
|
|
2017-11-09 17:16:25 +00:00
|
|
|
e.emit();
|
2017-11-06 08:49:47 +00:00
|
|
|
}
|
|
|
|
|
2016-06-02 21:47:34 +08:00
|
|
|
/// Actually verifies and tracks a given format placeholder
|
|
|
|
/// (a.k.a. argument).
|
2013-12-25 21:55:05 -08:00
|
|
|
fn verify_arg_type(&mut self, arg: Position, ty: ArgumentType) {
|
2013-07-29 01:12:41 -07:00
|
|
|
match arg {
|
2013-12-25 21:55:05 -08:00
|
|
|
Exact(arg) => {
|
2014-05-04 20:48:16 +02:00
|
|
|
if self.args.len() <= arg {
|
2017-11-06 08:49:47 +00:00
|
|
|
self.invalid_refs.push(arg);
|
2013-07-29 01:12:41 -07:00
|
|
|
return;
|
|
|
|
}
|
2016-05-21 16:00:01 +08:00
|
|
|
match ty {
|
|
|
|
Placeholder(_) => {
|
2016-06-02 18:16:24 +08:00
|
|
|
// record every (position, type) combination only once
|
|
|
|
let ref mut seen_ty = self.arg_unique_types[arg];
|
|
|
|
let i = match seen_ty.iter().position(|x| *x == ty) {
|
|
|
|
Some(i) => i,
|
|
|
|
None => {
|
|
|
|
let i = seen_ty.len();
|
|
|
|
seen_ty.push(ty);
|
|
|
|
i
|
|
|
|
}
|
|
|
|
};
|
|
|
|
self.arg_types[arg].push(i);
|
2016-05-21 16:00:01 +08:00
|
|
|
}
|
|
|
|
Count => {
|
|
|
|
match self.count_positions.entry(arg) {
|
|
|
|
Entry::Vacant(e) => {
|
|
|
|
let i = self.count_positions_count;
|
|
|
|
e.insert(i);
|
|
|
|
self.count_args.push(Exact(arg));
|
|
|
|
self.count_positions_count += 1;
|
|
|
|
}
|
|
|
|
Entry::Occupied(_) => {}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
|
2013-12-25 21:55:05 -08:00
|
|
|
Named(name) => {
|
2016-06-05 20:39:05 +08:00
|
|
|
let idx = match self.names.get(&name) {
|
|
|
|
Some(e) => *e,
|
2013-07-29 01:12:41 -07:00
|
|
|
None => {
|
2013-09-27 21:01:58 -07:00
|
|
|
let msg = format!("there is no argument named `{}`", name);
|
2015-02-18 14:48:57 -05:00
|
|
|
self.ecx.span_err(self.fmtsp, &msg[..]);
|
2013-07-29 01:12:41 -07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
};
|
2016-06-05 20:39:05 +08:00
|
|
|
// Treat as positional arg.
|
|
|
|
self.verify_arg_type(Exact(idx), ty)
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-02 21:47:34 +08:00
|
|
|
/// Builds the mapping between format placeholders and argument objects.
|
2016-05-14 20:42:47 +08:00
|
|
|
fn build_index_map(&mut self) {
|
2016-06-02 21:47:34 +08:00
|
|
|
// NOTE: Keep the ordering the same as `into_expr`'s expansion would do!
|
2016-05-14 20:42:47 +08:00
|
|
|
let args_len = self.args.len();
|
|
|
|
self.arg_index_map.reserve(args_len);
|
|
|
|
|
|
|
|
let mut sofar = 0usize;
|
|
|
|
|
2016-06-02 21:47:34 +08:00
|
|
|
// Map the arguments
|
2016-05-14 20:42:47 +08:00
|
|
|
for i in 0..args_len {
|
2016-06-02 18:16:24 +08:00
|
|
|
let ref arg_types = self.arg_types[i];
|
|
|
|
let mut arg_offsets = Vec::with_capacity(arg_types.len());
|
|
|
|
for offset in arg_types {
|
|
|
|
arg_offsets.push(sofar + *offset);
|
|
|
|
}
|
|
|
|
self.arg_index_map.push(arg_offsets);
|
|
|
|
sofar += self.arg_unique_types[i].len();
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
2016-05-21 16:00:01 +08:00
|
|
|
|
2016-06-02 21:47:34 +08:00
|
|
|
// Record starting index for counts, which appear just after arguments
|
2016-05-21 16:00:01 +08:00
|
|
|
self.count_args_index_offset = sofar;
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
|
2014-09-13 19:06:01 +03:00
|
|
|
fn rtpath(ecx: &ExtCtxt, s: &str) -> Vec<ast::Ident> {
|
2015-07-29 17:01:14 -07:00
|
|
|
ecx.std_path(&["fmt", "rt", "v1", s])
|
2014-02-07 14:45:46 -05:00
|
|
|
}
|
|
|
|
|
2018-05-08 16:10:16 +03:00
|
|
|
fn build_count(&self, c: parse::Count) -> P<ast::Expr> {
|
2015-04-10 04:11:21 -07:00
|
|
|
let sp = self.macsp;
|
2015-02-01 12:44:15 -05:00
|
|
|
let count = |c, arg| {
|
std: Stabilize the std::fmt module
This commit performs a final stabilization pass over the std::fmt module,
marking all necessary APIs as stable. One of the more interesting aspects of
this module is that it exposes a good deal of its runtime representation to the
outside world in order for `format_args!` to be able to construct the format
strings. Instead of hacking the compiler to assume that these items are stable,
this commit instead lays out a story for the stabilization and evolution of
these APIs.
There are three primary details used by the `format_args!` macro:
1. `Arguments` - an opaque package of a "compiled format string". This structure
is passed around and the `write` function is the source of truth for
transforming a compiled format string into a string at runtime. This must be
able to be constructed in stable code.
2. `Argument` - an opaque structure representing an argument to a format string.
This is *almost* a trait object as it's just a pointer/function pair, but due
to the function originating from one of many traits, it's not actually a
trait object. Like `Arguments`, this must be constructed from stable code.
3. `fmt::rt` - this module contains the runtime type definitions primarily for
the `rt::Argument` structure. Whenever an argument is formatted with
nonstandard flags, a corresponding `rt::Argument` is generated describing how
the argument is being formatted. This can be used to construct an
`Arguments`.
The primary interface to `std::fmt` is the `Arguments` structure, and as such
this type name is stabilize as-is today. It is expected for libraries to pass
around an `Arguments` structure to represent a pending formatted computation.
The remaining portions are largely "cruft" which would rather not be stabilized,
but due to the stability checks they must be. As a result, almost all pieces
have been renamed to represent that they are "version 1" of the formatting
representation. The theory is that at a later date if we change the
representation of these types we can add new definitions called "version 2" and
corresponding constructors for `Arguments`.
One of the other remaining large questions about the fmt module were how the
pending I/O reform would affect the signatures of methods in the module. Due to
[RFC 526][rfc], however, the writers of fmt are now incompatible with the
writers of io, so this question has largely been solved. As a result the
interfaces are largely stabilized as-is today.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
Specifically, the following changes were made:
* The contents of `fmt::rt` were all moved under `fmt::rt::v1`
* `fmt::rt` is stable
* `fmt::rt::v1` is stable
* `Error` is stable
* `Writer` is stable
* `Writer::write_str` is stable
* `Writer::write_fmt` is stable
* `Formatter` is stable
* `Argument` has been renamed to `ArgumentV1` and is stable
* `ArgumentV1::new` is stable
* `ArgumentV1::from_uint` is stable
* `Arguments::new_v1` is stable (renamed from `new`)
* `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`)
* All formatting traits are now stable, as well as the `fmt` method.
* `fmt::write` is stable
* `fmt::format` is stable
* `Formatter::pad_integral` is stable
* `Formatter::pad` is stable
* `Formatter::write_str` is stable
* `Formatter::write_fmt` is stable
* Some assorted top level items which were only used by `format_args!` were
removed in favor of static functions on `ArgumentV1` as well.
* The formatting-flag-accessing methods remain unstable
Within the contents of the `fmt::rt::v1` module, the following actions were
taken:
* Reexports of all enum variants were removed
* All prefixes on enum variants were removed
* A few miscellaneous enum variants were renamed
* Otherwise all structs, fields, and variants were marked stable.
In addition to these actions in the `std::fmt` module, many implementations of
`Show` and `String` were stabilized as well.
In some other modules:
* `ToString` is now stable
* `ToString::to_string` is now stable
* `Vec` no longer implements `fmt::Writer` (this has moved to `String`)
This is a breaking change due to all of the changes to the `fmt::rt` module, but
this likely will not have much impact on existing programs.
Closes #20661
[breaking-change]
2015-01-13 15:42:53 -08:00
|
|
|
let mut path = Context::rtpath(self.ecx, "Count");
|
|
|
|
path.push(self.ecx.ident_of(c));
|
|
|
|
match arg {
|
|
|
|
Some(arg) => self.ecx.expr_call_global(sp, path, vec![arg]),
|
|
|
|
None => self.ecx.expr_path(self.ecx.path_global(sp, path)),
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
std: Stabilize the std::fmt module
This commit performs a final stabilization pass over the std::fmt module,
marking all necessary APIs as stable. One of the more interesting aspects of
this module is that it exposes a good deal of its runtime representation to the
outside world in order for `format_args!` to be able to construct the format
strings. Instead of hacking the compiler to assume that these items are stable,
this commit instead lays out a story for the stabilization and evolution of
these APIs.
There are three primary details used by the `format_args!` macro:
1. `Arguments` - an opaque package of a "compiled format string". This structure
is passed around and the `write` function is the source of truth for
transforming a compiled format string into a string at runtime. This must be
able to be constructed in stable code.
2. `Argument` - an opaque structure representing an argument to a format string.
This is *almost* a trait object as it's just a pointer/function pair, but due
to the function originating from one of many traits, it's not actually a
trait object. Like `Arguments`, this must be constructed from stable code.
3. `fmt::rt` - this module contains the runtime type definitions primarily for
the `rt::Argument` structure. Whenever an argument is formatted with
nonstandard flags, a corresponding `rt::Argument` is generated describing how
the argument is being formatted. This can be used to construct an
`Arguments`.
The primary interface to `std::fmt` is the `Arguments` structure, and as such
this type name is stabilize as-is today. It is expected for libraries to pass
around an `Arguments` structure to represent a pending formatted computation.
The remaining portions are largely "cruft" which would rather not be stabilized,
but due to the stability checks they must be. As a result, almost all pieces
have been renamed to represent that they are "version 1" of the formatting
representation. The theory is that at a later date if we change the
representation of these types we can add new definitions called "version 2" and
corresponding constructors for `Arguments`.
One of the other remaining large questions about the fmt module were how the
pending I/O reform would affect the signatures of methods in the module. Due to
[RFC 526][rfc], however, the writers of fmt are now incompatible with the
writers of io, so this question has largely been solved. As a result the
interfaces are largely stabilized as-is today.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
Specifically, the following changes were made:
* The contents of `fmt::rt` were all moved under `fmt::rt::v1`
* `fmt::rt` is stable
* `fmt::rt::v1` is stable
* `Error` is stable
* `Writer` is stable
* `Writer::write_str` is stable
* `Writer::write_fmt` is stable
* `Formatter` is stable
* `Argument` has been renamed to `ArgumentV1` and is stable
* `ArgumentV1::new` is stable
* `ArgumentV1::from_uint` is stable
* `Arguments::new_v1` is stable (renamed from `new`)
* `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`)
* All formatting traits are now stable, as well as the `fmt` method.
* `fmt::write` is stable
* `fmt::format` is stable
* `Formatter::pad_integral` is stable
* `Formatter::pad` is stable
* `Formatter::write_str` is stable
* `Formatter::write_fmt` is stable
* Some assorted top level items which were only used by `format_args!` were
removed in favor of static functions on `ArgumentV1` as well.
* The formatting-flag-accessing methods remain unstable
Within the contents of the `fmt::rt::v1` module, the following actions were
taken:
* Reexports of all enum variants were removed
* All prefixes on enum variants were removed
* A few miscellaneous enum variants were renamed
* Otherwise all structs, fields, and variants were marked stable.
In addition to these actions in the `std::fmt` module, many implementations of
`Show` and `String` were stabilized as well.
In some other modules:
* `ToString` is now stable
* `ToString::to_string` is now stable
* `Vec` no longer implements `fmt::Writer` (this has moved to `String`)
This is a breaking change due to all of the changes to the `fmt::rt` module, but
this likely will not have much impact on existing programs.
Closes #20661
[breaking-change]
2015-01-13 15:42:53 -08:00
|
|
|
};
|
|
|
|
match c {
|
|
|
|
parse::CountIs(i) => count("Is", Some(self.ecx.expr_usize(sp, i))),
|
2014-02-07 14:45:46 -05:00
|
|
|
parse::CountIsParam(i) => {
|
2016-05-14 20:42:47 +08:00
|
|
|
// This needs mapping too, as `i` is referring to a macro
|
|
|
|
// argument.
|
2016-05-21 16:00:01 +08:00
|
|
|
let i = match self.count_positions.get(&i) {
|
|
|
|
Some(&i) => i,
|
|
|
|
None => 0, // error already emitted elsewhere
|
|
|
|
};
|
|
|
|
let i = i + self.count_args_index_offset;
|
|
|
|
count("Param", Some(self.ecx.expr_usize(sp, i)))
|
2014-02-07 14:45:46 -05:00
|
|
|
}
|
std: Stabilize the std::fmt module
This commit performs a final stabilization pass over the std::fmt module,
marking all necessary APIs as stable. One of the more interesting aspects of
this module is that it exposes a good deal of its runtime representation to the
outside world in order for `format_args!` to be able to construct the format
strings. Instead of hacking the compiler to assume that these items are stable,
this commit instead lays out a story for the stabilization and evolution of
these APIs.
There are three primary details used by the `format_args!` macro:
1. `Arguments` - an opaque package of a "compiled format string". This structure
is passed around and the `write` function is the source of truth for
transforming a compiled format string into a string at runtime. This must be
able to be constructed in stable code.
2. `Argument` - an opaque structure representing an argument to a format string.
This is *almost* a trait object as it's just a pointer/function pair, but due
to the function originating from one of many traits, it's not actually a
trait object. Like `Arguments`, this must be constructed from stable code.
3. `fmt::rt` - this module contains the runtime type definitions primarily for
the `rt::Argument` structure. Whenever an argument is formatted with
nonstandard flags, a corresponding `rt::Argument` is generated describing how
the argument is being formatted. This can be used to construct an
`Arguments`.
The primary interface to `std::fmt` is the `Arguments` structure, and as such
this type name is stabilize as-is today. It is expected for libraries to pass
around an `Arguments` structure to represent a pending formatted computation.
The remaining portions are largely "cruft" which would rather not be stabilized,
but due to the stability checks they must be. As a result, almost all pieces
have been renamed to represent that they are "version 1" of the formatting
representation. The theory is that at a later date if we change the
representation of these types we can add new definitions called "version 2" and
corresponding constructors for `Arguments`.
One of the other remaining large questions about the fmt module were how the
pending I/O reform would affect the signatures of methods in the module. Due to
[RFC 526][rfc], however, the writers of fmt are now incompatible with the
writers of io, so this question has largely been solved. As a result the
interfaces are largely stabilized as-is today.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
Specifically, the following changes were made:
* The contents of `fmt::rt` were all moved under `fmt::rt::v1`
* `fmt::rt` is stable
* `fmt::rt::v1` is stable
* `Error` is stable
* `Writer` is stable
* `Writer::write_str` is stable
* `Writer::write_fmt` is stable
* `Formatter` is stable
* `Argument` has been renamed to `ArgumentV1` and is stable
* `ArgumentV1::new` is stable
* `ArgumentV1::from_uint` is stable
* `Arguments::new_v1` is stable (renamed from `new`)
* `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`)
* All formatting traits are now stable, as well as the `fmt` method.
* `fmt::write` is stable
* `fmt::format` is stable
* `Formatter::pad_integral` is stable
* `Formatter::pad` is stable
* `Formatter::write_str` is stable
* `Formatter::write_fmt` is stable
* Some assorted top level items which were only used by `format_args!` were
removed in favor of static functions on `ArgumentV1` as well.
* The formatting-flag-accessing methods remain unstable
Within the contents of the `fmt::rt::v1` module, the following actions were
taken:
* Reexports of all enum variants were removed
* All prefixes on enum variants were removed
* A few miscellaneous enum variants were renamed
* Otherwise all structs, fields, and variants were marked stable.
In addition to these actions in the `std::fmt` module, many implementations of
`Show` and `String` were stabilized as well.
In some other modules:
* `ToString` is now stable
* `ToString::to_string` is now stable
* `Vec` no longer implements `fmt::Writer` (this has moved to `String`)
This is a breaking change due to all of the changes to the `fmt::rt` module, but
this likely will not have much impact on existing programs.
Closes #20661
[breaking-change]
2015-01-13 15:42:53 -08:00
|
|
|
parse::CountImplied => count("Implied", None),
|
2016-06-05 20:39:05 +08:00
|
|
|
// should never be the case, names are already resolved
|
|
|
|
parse::CountIsName(_) => panic!("should never happen"),
|
2014-02-07 14:45:46 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-08 16:10:16 +03:00
|
|
|
/// Build a literal expression from the accumulated string literals
|
|
|
|
fn build_literal_string(&mut self) -> P<ast::Expr> {
|
2014-07-20 16:31:43 +02:00
|
|
|
let sp = self.fmtsp;
|
2016-11-16 10:52:37 +00:00
|
|
|
let s = Symbol::intern(&self.literal);
|
2014-08-21 14:34:00 +01:00
|
|
|
self.literal.clear();
|
|
|
|
self.ecx.expr_str(sp, s)
|
2014-07-20 16:31:43 +02:00
|
|
|
}
|
|
|
|
|
2018-05-08 16:10:16 +03:00
|
|
|
/// Build a static `rt::Argument` from a `parse::Piece` or append
|
2014-08-21 14:34:00 +01:00
|
|
|
/// to the `literal` string.
|
2018-05-08 16:10:16 +03:00
|
|
|
fn build_piece(&mut self,
|
2016-05-14 20:42:47 +08:00
|
|
|
piece: &parse::Piece,
|
|
|
|
arg_index_consumed: &mut Vec<usize>)
|
|
|
|
-> Option<P<ast::Expr>> {
|
2015-04-10 04:11:21 -07:00
|
|
|
let sp = self.macsp;
|
2013-07-29 01:12:41 -07:00
|
|
|
match *piece {
|
|
|
|
parse::String(s) => {
|
2014-08-21 14:34:00 +01:00
|
|
|
self.literal.push_str(s);
|
2014-07-20 16:31:43 +02:00
|
|
|
None
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
2014-09-11 17:07:49 +12:00
|
|
|
parse::NextArgument(ref arg) => {
|
2018-05-08 16:10:16 +03:00
|
|
|
// Build the position
|
std: Stabilize the std::fmt module
This commit performs a final stabilization pass over the std::fmt module,
marking all necessary APIs as stable. One of the more interesting aspects of
this module is that it exposes a good deal of its runtime representation to the
outside world in order for `format_args!` to be able to construct the format
strings. Instead of hacking the compiler to assume that these items are stable,
this commit instead lays out a story for the stabilization and evolution of
these APIs.
There are three primary details used by the `format_args!` macro:
1. `Arguments` - an opaque package of a "compiled format string". This structure
is passed around and the `write` function is the source of truth for
transforming a compiled format string into a string at runtime. This must be
able to be constructed in stable code.
2. `Argument` - an opaque structure representing an argument to a format string.
This is *almost* a trait object as it's just a pointer/function pair, but due
to the function originating from one of many traits, it's not actually a
trait object. Like `Arguments`, this must be constructed from stable code.
3. `fmt::rt` - this module contains the runtime type definitions primarily for
the `rt::Argument` structure. Whenever an argument is formatted with
nonstandard flags, a corresponding `rt::Argument` is generated describing how
the argument is being formatted. This can be used to construct an
`Arguments`.
The primary interface to `std::fmt` is the `Arguments` structure, and as such
this type name is stabilize as-is today. It is expected for libraries to pass
around an `Arguments` structure to represent a pending formatted computation.
The remaining portions are largely "cruft" which would rather not be stabilized,
but due to the stability checks they must be. As a result, almost all pieces
have been renamed to represent that they are "version 1" of the formatting
representation. The theory is that at a later date if we change the
representation of these types we can add new definitions called "version 2" and
corresponding constructors for `Arguments`.
One of the other remaining large questions about the fmt module were how the
pending I/O reform would affect the signatures of methods in the module. Due to
[RFC 526][rfc], however, the writers of fmt are now incompatible with the
writers of io, so this question has largely been solved. As a result the
interfaces are largely stabilized as-is today.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
Specifically, the following changes were made:
* The contents of `fmt::rt` were all moved under `fmt::rt::v1`
* `fmt::rt` is stable
* `fmt::rt::v1` is stable
* `Error` is stable
* `Writer` is stable
* `Writer::write_str` is stable
* `Writer::write_fmt` is stable
* `Formatter` is stable
* `Argument` has been renamed to `ArgumentV1` and is stable
* `ArgumentV1::new` is stable
* `ArgumentV1::from_uint` is stable
* `Arguments::new_v1` is stable (renamed from `new`)
* `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`)
* All formatting traits are now stable, as well as the `fmt` method.
* `fmt::write` is stable
* `fmt::format` is stable
* `Formatter::pad_integral` is stable
* `Formatter::pad` is stable
* `Formatter::write_str` is stable
* `Formatter::write_fmt` is stable
* Some assorted top level items which were only used by `format_args!` were
removed in favor of static functions on `ArgumentV1` as well.
* The formatting-flag-accessing methods remain unstable
Within the contents of the `fmt::rt::v1` module, the following actions were
taken:
* Reexports of all enum variants were removed
* All prefixes on enum variants were removed
* A few miscellaneous enum variants were renamed
* Otherwise all structs, fields, and variants were marked stable.
In addition to these actions in the `std::fmt` module, many implementations of
`Show` and `String` were stabilized as well.
In some other modules:
* `ToString` is now stable
* `ToString::to_string` is now stable
* `Vec` no longer implements `fmt::Writer` (this has moved to `String`)
This is a breaking change due to all of the changes to the `fmt::rt` module, but
this likely will not have much impact on existing programs.
Closes #20661
[breaking-change]
2015-01-13 15:42:53 -08:00
|
|
|
let pos = {
|
2015-02-01 12:44:15 -05:00
|
|
|
let pos = |c, arg| {
|
std: Stabilize the std::fmt module
This commit performs a final stabilization pass over the std::fmt module,
marking all necessary APIs as stable. One of the more interesting aspects of
this module is that it exposes a good deal of its runtime representation to the
outside world in order for `format_args!` to be able to construct the format
strings. Instead of hacking the compiler to assume that these items are stable,
this commit instead lays out a story for the stabilization and evolution of
these APIs.
There are three primary details used by the `format_args!` macro:
1. `Arguments` - an opaque package of a "compiled format string". This structure
is passed around and the `write` function is the source of truth for
transforming a compiled format string into a string at runtime. This must be
able to be constructed in stable code.
2. `Argument` - an opaque structure representing an argument to a format string.
This is *almost* a trait object as it's just a pointer/function pair, but due
to the function originating from one of many traits, it's not actually a
trait object. Like `Arguments`, this must be constructed from stable code.
3. `fmt::rt` - this module contains the runtime type definitions primarily for
the `rt::Argument` structure. Whenever an argument is formatted with
nonstandard flags, a corresponding `rt::Argument` is generated describing how
the argument is being formatted. This can be used to construct an
`Arguments`.
The primary interface to `std::fmt` is the `Arguments` structure, and as such
this type name is stabilize as-is today. It is expected for libraries to pass
around an `Arguments` structure to represent a pending formatted computation.
The remaining portions are largely "cruft" which would rather not be stabilized,
but due to the stability checks they must be. As a result, almost all pieces
have been renamed to represent that they are "version 1" of the formatting
representation. The theory is that at a later date if we change the
representation of these types we can add new definitions called "version 2" and
corresponding constructors for `Arguments`.
One of the other remaining large questions about the fmt module were how the
pending I/O reform would affect the signatures of methods in the module. Due to
[RFC 526][rfc], however, the writers of fmt are now incompatible with the
writers of io, so this question has largely been solved. As a result the
interfaces are largely stabilized as-is today.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
Specifically, the following changes were made:
* The contents of `fmt::rt` were all moved under `fmt::rt::v1`
* `fmt::rt` is stable
* `fmt::rt::v1` is stable
* `Error` is stable
* `Writer` is stable
* `Writer::write_str` is stable
* `Writer::write_fmt` is stable
* `Formatter` is stable
* `Argument` has been renamed to `ArgumentV1` and is stable
* `ArgumentV1::new` is stable
* `ArgumentV1::from_uint` is stable
* `Arguments::new_v1` is stable (renamed from `new`)
* `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`)
* All formatting traits are now stable, as well as the `fmt` method.
* `fmt::write` is stable
* `fmt::format` is stable
* `Formatter::pad_integral` is stable
* `Formatter::pad` is stable
* `Formatter::write_str` is stable
* `Formatter::write_fmt` is stable
* Some assorted top level items which were only used by `format_args!` were
removed in favor of static functions on `ArgumentV1` as well.
* The formatting-flag-accessing methods remain unstable
Within the contents of the `fmt::rt::v1` module, the following actions were
taken:
* Reexports of all enum variants were removed
* All prefixes on enum variants were removed
* A few miscellaneous enum variants were renamed
* Otherwise all structs, fields, and variants were marked stable.
In addition to these actions in the `std::fmt` module, many implementations of
`Show` and `String` were stabilized as well.
In some other modules:
* `ToString` is now stable
* `ToString::to_string` is now stable
* `Vec` no longer implements `fmt::Writer` (this has moved to `String`)
This is a breaking change due to all of the changes to the `fmt::rt` module, but
this likely will not have much impact on existing programs.
Closes #20661
[breaking-change]
2015-01-13 15:42:53 -08:00
|
|
|
let mut path = Context::rtpath(self.ecx, "Position");
|
|
|
|
path.push(self.ecx.ident_of(c));
|
|
|
|
match arg {
|
|
|
|
Some(i) => {
|
|
|
|
let arg = self.ecx.expr_usize(sp, i);
|
|
|
|
self.ecx.expr_call_global(sp, path, vec![arg])
|
|
|
|
}
|
2016-06-06 20:22:48 +05:30
|
|
|
None => self.ecx.expr_path(self.ecx.path_global(sp, path)),
|
std: Stabilize the std::fmt module
This commit performs a final stabilization pass over the std::fmt module,
marking all necessary APIs as stable. One of the more interesting aspects of
this module is that it exposes a good deal of its runtime representation to the
outside world in order for `format_args!` to be able to construct the format
strings. Instead of hacking the compiler to assume that these items are stable,
this commit instead lays out a story for the stabilization and evolution of
these APIs.
There are three primary details used by the `format_args!` macro:
1. `Arguments` - an opaque package of a "compiled format string". This structure
is passed around and the `write` function is the source of truth for
transforming a compiled format string into a string at runtime. This must be
able to be constructed in stable code.
2. `Argument` - an opaque structure representing an argument to a format string.
This is *almost* a trait object as it's just a pointer/function pair, but due
to the function originating from one of many traits, it's not actually a
trait object. Like `Arguments`, this must be constructed from stable code.
3. `fmt::rt` - this module contains the runtime type definitions primarily for
the `rt::Argument` structure. Whenever an argument is formatted with
nonstandard flags, a corresponding `rt::Argument` is generated describing how
the argument is being formatted. This can be used to construct an
`Arguments`.
The primary interface to `std::fmt` is the `Arguments` structure, and as such
this type name is stabilize as-is today. It is expected for libraries to pass
around an `Arguments` structure to represent a pending formatted computation.
The remaining portions are largely "cruft" which would rather not be stabilized,
but due to the stability checks they must be. As a result, almost all pieces
have been renamed to represent that they are "version 1" of the formatting
representation. The theory is that at a later date if we change the
representation of these types we can add new definitions called "version 2" and
corresponding constructors for `Arguments`.
One of the other remaining large questions about the fmt module were how the
pending I/O reform would affect the signatures of methods in the module. Due to
[RFC 526][rfc], however, the writers of fmt are now incompatible with the
writers of io, so this question has largely been solved. As a result the
interfaces are largely stabilized as-is today.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
Specifically, the following changes were made:
* The contents of `fmt::rt` were all moved under `fmt::rt::v1`
* `fmt::rt` is stable
* `fmt::rt::v1` is stable
* `Error` is stable
* `Writer` is stable
* `Writer::write_str` is stable
* `Writer::write_fmt` is stable
* `Formatter` is stable
* `Argument` has been renamed to `ArgumentV1` and is stable
* `ArgumentV1::new` is stable
* `ArgumentV1::from_uint` is stable
* `Arguments::new_v1` is stable (renamed from `new`)
* `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`)
* All formatting traits are now stable, as well as the `fmt` method.
* `fmt::write` is stable
* `fmt::format` is stable
* `Formatter::pad_integral` is stable
* `Formatter::pad` is stable
* `Formatter::write_str` is stable
* `Formatter::write_fmt` is stable
* Some assorted top level items which were only used by `format_args!` were
removed in favor of static functions on `ArgumentV1` as well.
* The formatting-flag-accessing methods remain unstable
Within the contents of the `fmt::rt::v1` module, the following actions were
taken:
* Reexports of all enum variants were removed
* All prefixes on enum variants were removed
* A few miscellaneous enum variants were renamed
* Otherwise all structs, fields, and variants were marked stable.
In addition to these actions in the `std::fmt` module, many implementations of
`Show` and `String` were stabilized as well.
In some other modules:
* `ToString` is now stable
* `ToString::to_string` is now stable
* `Vec` no longer implements `fmt::Writer` (this has moved to `String`)
This is a breaking change due to all of the changes to the `fmt::rt` module, but
this likely will not have much impact on existing programs.
Closes #20661
[breaking-change]
2015-01-13 15:42:53 -08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
match arg.position {
|
2017-11-09 17:16:25 +00:00
|
|
|
parse::ArgumentIs(i)
|
|
|
|
| parse::ArgumentImplicitlyIs(i) => {
|
2016-05-14 20:42:47 +08:00
|
|
|
// Map to index in final generated argument array
|
|
|
|
// in case of multiple types specified
|
2016-06-02 18:16:24 +08:00
|
|
|
let arg_idx = match arg_index_consumed.get_mut(i) {
|
|
|
|
None => 0, // error already emitted elsewhere
|
|
|
|
Some(offset) => {
|
2016-07-29 16:40:10 +08:00
|
|
|
let ref idx_map = self.arg_index_map[i];
|
|
|
|
// unwrap_or branch: error already emitted elsewhere
|
|
|
|
let arg_idx = *idx_map.get(*offset).unwrap_or(&0);
|
2016-06-02 18:16:24 +08:00
|
|
|
*offset += 1;
|
|
|
|
arg_idx
|
|
|
|
}
|
2016-05-14 20:42:47 +08:00
|
|
|
};
|
|
|
|
pos("At", Some(arg_idx))
|
|
|
|
}
|
std: Stabilize the std::fmt module
This commit performs a final stabilization pass over the std::fmt module,
marking all necessary APIs as stable. One of the more interesting aspects of
this module is that it exposes a good deal of its runtime representation to the
outside world in order for `format_args!` to be able to construct the format
strings. Instead of hacking the compiler to assume that these items are stable,
this commit instead lays out a story for the stabilization and evolution of
these APIs.
There are three primary details used by the `format_args!` macro:
1. `Arguments` - an opaque package of a "compiled format string". This structure
is passed around and the `write` function is the source of truth for
transforming a compiled format string into a string at runtime. This must be
able to be constructed in stable code.
2. `Argument` - an opaque structure representing an argument to a format string.
This is *almost* a trait object as it's just a pointer/function pair, but due
to the function originating from one of many traits, it's not actually a
trait object. Like `Arguments`, this must be constructed from stable code.
3. `fmt::rt` - this module contains the runtime type definitions primarily for
the `rt::Argument` structure. Whenever an argument is formatted with
nonstandard flags, a corresponding `rt::Argument` is generated describing how
the argument is being formatted. This can be used to construct an
`Arguments`.
The primary interface to `std::fmt` is the `Arguments` structure, and as such
this type name is stabilize as-is today. It is expected for libraries to pass
around an `Arguments` structure to represent a pending formatted computation.
The remaining portions are largely "cruft" which would rather not be stabilized,
but due to the stability checks they must be. As a result, almost all pieces
have been renamed to represent that they are "version 1" of the formatting
representation. The theory is that at a later date if we change the
representation of these types we can add new definitions called "version 2" and
corresponding constructors for `Arguments`.
One of the other remaining large questions about the fmt module were how the
pending I/O reform would affect the signatures of methods in the module. Due to
[RFC 526][rfc], however, the writers of fmt are now incompatible with the
writers of io, so this question has largely been solved. As a result the
interfaces are largely stabilized as-is today.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
Specifically, the following changes were made:
* The contents of `fmt::rt` were all moved under `fmt::rt::v1`
* `fmt::rt` is stable
* `fmt::rt::v1` is stable
* `Error` is stable
* `Writer` is stable
* `Writer::write_str` is stable
* `Writer::write_fmt` is stable
* `Formatter` is stable
* `Argument` has been renamed to `ArgumentV1` and is stable
* `ArgumentV1::new` is stable
* `ArgumentV1::from_uint` is stable
* `Arguments::new_v1` is stable (renamed from `new`)
* `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`)
* All formatting traits are now stable, as well as the `fmt` method.
* `fmt::write` is stable
* `fmt::format` is stable
* `Formatter::pad_integral` is stable
* `Formatter::pad` is stable
* `Formatter::write_str` is stable
* `Formatter::write_fmt` is stable
* Some assorted top level items which were only used by `format_args!` were
removed in favor of static functions on `ArgumentV1` as well.
* The formatting-flag-accessing methods remain unstable
Within the contents of the `fmt::rt::v1` module, the following actions were
taken:
* Reexports of all enum variants were removed
* All prefixes on enum variants were removed
* A few miscellaneous enum variants were renamed
* Otherwise all structs, fields, and variants were marked stable.
In addition to these actions in the `std::fmt` module, many implementations of
`Show` and `String` were stabilized as well.
In some other modules:
* `ToString` is now stable
* `ToString::to_string` is now stable
* `Vec` no longer implements `fmt::Writer` (this has moved to `String`)
This is a breaking change due to all of the changes to the `fmt::rt` module, but
this likely will not have much impact on existing programs.
Closes #20661
[breaking-change]
2015-01-13 15:42:53 -08:00
|
|
|
|
2016-06-05 20:39:05 +08:00
|
|
|
// should never be the case, because names are already
|
|
|
|
// resolved.
|
|
|
|
parse::ArgumentNamed(_) => panic!("should never happen"),
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2014-08-25 14:26:18 +01:00
|
|
|
let simple_arg = parse::Argument {
|
2016-05-17 01:02:42 +08:00
|
|
|
position: {
|
|
|
|
// We don't have ArgumentNext any more, so we have to
|
|
|
|
// track the current argument ourselves.
|
|
|
|
let i = self.curarg;
|
|
|
|
self.curarg += 1;
|
|
|
|
parse::ArgumentIs(i)
|
|
|
|
},
|
2014-08-25 14:26:18 +01:00
|
|
|
format: parse::FormatSpec {
|
|
|
|
fill: arg.format.fill,
|
|
|
|
align: parse::AlignUnknown,
|
|
|
|
flags: 0,
|
|
|
|
precision: parse::CountImplied,
|
|
|
|
width: parse::CountImplied,
|
2016-06-06 20:22:48 +05:30
|
|
|
ty: arg.format.ty,
|
|
|
|
},
|
2014-08-25 14:26:18 +01:00
|
|
|
};
|
|
|
|
|
2016-06-06 20:22:48 +05:30
|
|
|
let fill = match arg.format.fill {
|
|
|
|
Some(c) => c,
|
|
|
|
None => ' ',
|
|
|
|
};
|
2014-08-25 14:26:18 +01:00
|
|
|
|
|
|
|
if *arg != simple_arg || fill != ' ' {
|
|
|
|
self.all_pieces_simple = false;
|
|
|
|
}
|
|
|
|
|
2018-05-08 16:10:16 +03:00
|
|
|
// Build the format
|
2016-02-08 17:06:20 +01:00
|
|
|
let fill = self.ecx.expr_lit(sp, ast::LitKind::Char(fill));
|
2015-02-01 12:44:15 -05:00
|
|
|
let align = |name| {
|
std: Stabilize the std::fmt module
This commit performs a final stabilization pass over the std::fmt module,
marking all necessary APIs as stable. One of the more interesting aspects of
this module is that it exposes a good deal of its runtime representation to the
outside world in order for `format_args!` to be able to construct the format
strings. Instead of hacking the compiler to assume that these items are stable,
this commit instead lays out a story for the stabilization and evolution of
these APIs.
There are three primary details used by the `format_args!` macro:
1. `Arguments` - an opaque package of a "compiled format string". This structure
is passed around and the `write` function is the source of truth for
transforming a compiled format string into a string at runtime. This must be
able to be constructed in stable code.
2. `Argument` - an opaque structure representing an argument to a format string.
This is *almost* a trait object as it's just a pointer/function pair, but due
to the function originating from one of many traits, it's not actually a
trait object. Like `Arguments`, this must be constructed from stable code.
3. `fmt::rt` - this module contains the runtime type definitions primarily for
the `rt::Argument` structure. Whenever an argument is formatted with
nonstandard flags, a corresponding `rt::Argument` is generated describing how
the argument is being formatted. This can be used to construct an
`Arguments`.
The primary interface to `std::fmt` is the `Arguments` structure, and as such
this type name is stabilize as-is today. It is expected for libraries to pass
around an `Arguments` structure to represent a pending formatted computation.
The remaining portions are largely "cruft" which would rather not be stabilized,
but due to the stability checks they must be. As a result, almost all pieces
have been renamed to represent that they are "version 1" of the formatting
representation. The theory is that at a later date if we change the
representation of these types we can add new definitions called "version 2" and
corresponding constructors for `Arguments`.
One of the other remaining large questions about the fmt module were how the
pending I/O reform would affect the signatures of methods in the module. Due to
[RFC 526][rfc], however, the writers of fmt are now incompatible with the
writers of io, so this question has largely been solved. As a result the
interfaces are largely stabilized as-is today.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
Specifically, the following changes were made:
* The contents of `fmt::rt` were all moved under `fmt::rt::v1`
* `fmt::rt` is stable
* `fmt::rt::v1` is stable
* `Error` is stable
* `Writer` is stable
* `Writer::write_str` is stable
* `Writer::write_fmt` is stable
* `Formatter` is stable
* `Argument` has been renamed to `ArgumentV1` and is stable
* `ArgumentV1::new` is stable
* `ArgumentV1::from_uint` is stable
* `Arguments::new_v1` is stable (renamed from `new`)
* `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`)
* All formatting traits are now stable, as well as the `fmt` method.
* `fmt::write` is stable
* `fmt::format` is stable
* `Formatter::pad_integral` is stable
* `Formatter::pad` is stable
* `Formatter::write_str` is stable
* `Formatter::write_fmt` is stable
* Some assorted top level items which were only used by `format_args!` were
removed in favor of static functions on `ArgumentV1` as well.
* The formatting-flag-accessing methods remain unstable
Within the contents of the `fmt::rt::v1` module, the following actions were
taken:
* Reexports of all enum variants were removed
* All prefixes on enum variants were removed
* A few miscellaneous enum variants were renamed
* Otherwise all structs, fields, and variants were marked stable.
In addition to these actions in the `std::fmt` module, many implementations of
`Show` and `String` were stabilized as well.
In some other modules:
* `ToString` is now stable
* `ToString::to_string` is now stable
* `Vec` no longer implements `fmt::Writer` (this has moved to `String`)
This is a breaking change due to all of the changes to the `fmt::rt` module, but
this likely will not have much impact on existing programs.
Closes #20661
[breaking-change]
2015-01-13 15:42:53 -08:00
|
|
|
let mut p = Context::rtpath(self.ecx, "Alignment");
|
|
|
|
p.push(self.ecx.ident_of(name));
|
|
|
|
self.ecx.path_global(sp, p)
|
|
|
|
};
|
2013-07-29 01:12:41 -07:00
|
|
|
let align = match arg.format.align {
|
std: Stabilize the std::fmt module
This commit performs a final stabilization pass over the std::fmt module,
marking all necessary APIs as stable. One of the more interesting aspects of
this module is that it exposes a good deal of its runtime representation to the
outside world in order for `format_args!` to be able to construct the format
strings. Instead of hacking the compiler to assume that these items are stable,
this commit instead lays out a story for the stabilization and evolution of
these APIs.
There are three primary details used by the `format_args!` macro:
1. `Arguments` - an opaque package of a "compiled format string". This structure
is passed around and the `write` function is the source of truth for
transforming a compiled format string into a string at runtime. This must be
able to be constructed in stable code.
2. `Argument` - an opaque structure representing an argument to a format string.
This is *almost* a trait object as it's just a pointer/function pair, but due
to the function originating from one of many traits, it's not actually a
trait object. Like `Arguments`, this must be constructed from stable code.
3. `fmt::rt` - this module contains the runtime type definitions primarily for
the `rt::Argument` structure. Whenever an argument is formatted with
nonstandard flags, a corresponding `rt::Argument` is generated describing how
the argument is being formatted. This can be used to construct an
`Arguments`.
The primary interface to `std::fmt` is the `Arguments` structure, and as such
this type name is stabilize as-is today. It is expected for libraries to pass
around an `Arguments` structure to represent a pending formatted computation.
The remaining portions are largely "cruft" which would rather not be stabilized,
but due to the stability checks they must be. As a result, almost all pieces
have been renamed to represent that they are "version 1" of the formatting
representation. The theory is that at a later date if we change the
representation of these types we can add new definitions called "version 2" and
corresponding constructors for `Arguments`.
One of the other remaining large questions about the fmt module were how the
pending I/O reform would affect the signatures of methods in the module. Due to
[RFC 526][rfc], however, the writers of fmt are now incompatible with the
writers of io, so this question has largely been solved. As a result the
interfaces are largely stabilized as-is today.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
Specifically, the following changes were made:
* The contents of `fmt::rt` were all moved under `fmt::rt::v1`
* `fmt::rt` is stable
* `fmt::rt::v1` is stable
* `Error` is stable
* `Writer` is stable
* `Writer::write_str` is stable
* `Writer::write_fmt` is stable
* `Formatter` is stable
* `Argument` has been renamed to `ArgumentV1` and is stable
* `ArgumentV1::new` is stable
* `ArgumentV1::from_uint` is stable
* `Arguments::new_v1` is stable (renamed from `new`)
* `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`)
* All formatting traits are now stable, as well as the `fmt` method.
* `fmt::write` is stable
* `fmt::format` is stable
* `Formatter::pad_integral` is stable
* `Formatter::pad` is stable
* `Formatter::write_str` is stable
* `Formatter::write_fmt` is stable
* Some assorted top level items which were only used by `format_args!` were
removed in favor of static functions on `ArgumentV1` as well.
* The formatting-flag-accessing methods remain unstable
Within the contents of the `fmt::rt::v1` module, the following actions were
taken:
* Reexports of all enum variants were removed
* All prefixes on enum variants were removed
* A few miscellaneous enum variants were renamed
* Otherwise all structs, fields, and variants were marked stable.
In addition to these actions in the `std::fmt` module, many implementations of
`Show` and `String` were stabilized as well.
In some other modules:
* `ToString` is now stable
* `ToString::to_string` is now stable
* `Vec` no longer implements `fmt::Writer` (this has moved to `String`)
This is a breaking change due to all of the changes to the `fmt::rt` module, but
this likely will not have much impact on existing programs.
Closes #20661
[breaking-change]
2015-01-13 15:42:53 -08:00
|
|
|
parse::AlignLeft => align("Left"),
|
|
|
|
parse::AlignRight => align("Right"),
|
|
|
|
parse::AlignCenter => align("Center"),
|
|
|
|
parse::AlignUnknown => align("Unknown"),
|
2013-07-29 01:12:41 -07:00
|
|
|
};
|
2013-08-10 16:50:42 -07:00
|
|
|
let align = self.ecx.expr_path(align);
|
2015-02-23 16:07:38 +13:00
|
|
|
let flags = self.ecx.expr_u32(sp, arg.format.flags);
|
2018-05-08 16:10:16 +03:00
|
|
|
let prec = self.build_count(arg.format.precision);
|
|
|
|
let width = self.build_count(arg.format.width);
|
2014-09-13 19:06:01 +03:00
|
|
|
let path = self.ecx.path_global(sp, Context::rtpath(self.ecx, "FormatSpec"));
|
2016-06-06 20:22:48 +05:30
|
|
|
let fmt =
|
|
|
|
self.ecx.expr_struct(sp,
|
|
|
|
path,
|
|
|
|
vec![self.ecx
|
|
|
|
.field_imm(sp, self.ecx.ident_of("fill"), fill),
|
|
|
|
self.ecx.field_imm(sp,
|
|
|
|
self.ecx.ident_of("align"),
|
|
|
|
align),
|
|
|
|
self.ecx.field_imm(sp,
|
|
|
|
self.ecx.ident_of("flags"),
|
|
|
|
flags),
|
|
|
|
self.ecx.field_imm(sp,
|
|
|
|
self.ecx.ident_of("precision"),
|
|
|
|
prec),
|
|
|
|
self.ecx.field_imm(sp,
|
|
|
|
self.ecx.ident_of("width"),
|
|
|
|
width)]);
|
2013-07-29 01:12:41 -07:00
|
|
|
|
2014-09-13 19:06:01 +03:00
|
|
|
let path = self.ecx.path_global(sp, Context::rtpath(self.ecx, "Argument"));
|
2016-06-06 20:22:48 +05:30
|
|
|
Some(self.ecx.expr_struct(sp,
|
|
|
|
path,
|
|
|
|
vec![self.ecx.field_imm(sp,
|
|
|
|
self.ecx.ident_of("position"),
|
|
|
|
pos),
|
|
|
|
self.ecx.field_imm(sp,
|
|
|
|
self.ecx.ident_of("format"),
|
|
|
|
fmt)]))
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-02 21:47:34 +08:00
|
|
|
/// Actually builds the expression which the format_args! block will be
|
|
|
|
/// expanded to
|
2017-08-01 18:32:32 +01:00
|
|
|
fn into_expr(self) -> P<ast::Expr> {
|
2014-02-28 13:09:09 -08:00
|
|
|
let mut locals = Vec::new();
|
2016-05-21 16:00:01 +08:00
|
|
|
let mut counts = Vec::new();
|
2014-02-28 13:09:09 -08:00
|
|
|
let mut pats = Vec::new();
|
|
|
|
let mut heads = Vec::new();
|
2013-07-29 01:12:41 -07:00
|
|
|
|
2018-04-24 21:30:13 +01:00
|
|
|
let names_pos: Vec<_> = (0..self.args.len()).map(|i| {
|
|
|
|
self.ecx.ident_of(&format!("arg{}", i)).gensym()
|
|
|
|
}).collect();
|
|
|
|
|
2014-12-19 01:31:02 +02:00
|
|
|
// First, build up the static array which will become our precompiled
|
2013-07-29 01:12:41 -07:00
|
|
|
// format "string"
|
2017-09-04 13:23:49 +03:00
|
|
|
let pieces = self.ecx.expr_vec_slice(self.fmtsp, self.str_pieces);
|
2014-12-19 16:16:16 +02:00
|
|
|
|
2016-05-21 16:00:01 +08:00
|
|
|
// Before consuming the expressions, we have to remember spans for
|
|
|
|
// count arguments as they are now generated separate from other
|
|
|
|
// arguments, hence have no access to the `P<ast::Expr>`'s.
|
|
|
|
let spans_pos: Vec<_> = self.args.iter().map(|e| e.span.clone()).collect();
|
2013-07-29 01:12:41 -07:00
|
|
|
|
|
|
|
// Right now there is a bug such that for the expression:
|
|
|
|
// foo(bar(&1))
|
|
|
|
// the lifetime of `1` doesn't outlast the call to `bar`, so it's not
|
2014-09-02 01:35:58 -04:00
|
|
|
// valid for the call to `foo`. To work around this all arguments to the
|
2013-09-27 21:01:58 -07:00
|
|
|
// format! string are shoved into locals. Furthermore, we shove the address
|
2013-09-02 23:53:13 -07:00
|
|
|
// of each variable because we don't want to move out of the arguments
|
|
|
|
// passed to this function.
|
2014-09-14 20:27:36 -07:00
|
|
|
for (i, e) in self.args.into_iter().enumerate() {
|
2018-04-24 21:30:13 +01:00
|
|
|
let name = names_pos[i];
|
2017-07-31 23:04:34 +03:00
|
|
|
let span =
|
|
|
|
DUMMY_SP.with_ctxt(e.span.ctxt().apply_mark(self.ecx.current_expansion.mark));
|
2017-03-28 05:32:43 +00:00
|
|
|
pats.push(self.ecx.pat_ident(span, name));
|
2016-06-02 18:16:24 +08:00
|
|
|
for ref arg_ty in self.arg_unique_types[i].iter() {
|
2017-03-15 00:22:48 +00:00
|
|
|
locals.push(Context::format_arg(self.ecx, self.macsp, e.span, arg_ty, name));
|
2016-05-14 20:42:47 +08:00
|
|
|
}
|
2014-02-18 03:32:12 +08:00
|
|
|
heads.push(self.ecx.expr_addr_of(e.span, e));
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
2016-05-21 16:00:01 +08:00
|
|
|
for pos in self.count_args {
|
2018-04-24 21:30:13 +01:00
|
|
|
let index = match pos {
|
|
|
|
Exact(i) => i,
|
2016-05-21 16:00:01 +08:00
|
|
|
_ => panic!("should never happen"),
|
|
|
|
};
|
2018-04-24 21:30:13 +01:00
|
|
|
let name = names_pos[index];
|
|
|
|
let span = spans_pos[index];
|
2017-03-15 00:22:48 +00:00
|
|
|
counts.push(Context::format_arg(self.ecx, self.macsp, span, &Count, name));
|
2016-05-21 16:00:01 +08:00
|
|
|
}
|
2013-07-29 01:12:41 -07:00
|
|
|
|
2014-01-15 14:39:08 -05:00
|
|
|
// Now create a vector containing all the arguments
|
2016-05-21 16:00:01 +08:00
|
|
|
let args = locals.into_iter().chain(counts.into_iter());
|
2014-01-15 14:39:08 -05:00
|
|
|
|
2016-05-21 16:00:01 +08:00
|
|
|
let args_array = self.ecx.expr_vec(self.fmtsp, args.collect());
|
2014-12-20 21:57:47 +02:00
|
|
|
|
|
|
|
// Constructs an AST equivalent to:
|
|
|
|
//
|
|
|
|
// match (&arg0, &arg1) {
|
|
|
|
// (tmp0, tmp1) => args_array
|
|
|
|
// }
|
|
|
|
//
|
|
|
|
// It was:
|
|
|
|
//
|
|
|
|
// let tmp0 = &arg0;
|
|
|
|
// let tmp1 = &arg1;
|
|
|
|
// args_array
|
|
|
|
//
|
|
|
|
// Because of #11585 the new temporary lifetime rule, the enclosing
|
|
|
|
// statements for these temporaries become the let's themselves.
|
|
|
|
// If one or more of them are RefCell's, RefCell borrow() will also
|
|
|
|
// end there; they don't last long enough for args_array to use them.
|
|
|
|
// The match expression solves the scope problem.
|
|
|
|
//
|
|
|
|
// Note, it may also very well be transformed to:
|
|
|
|
//
|
|
|
|
// match arg0 {
|
|
|
|
// ref tmp0 => {
|
|
|
|
// match arg1 => {
|
|
|
|
// ref tmp1 => args_array } } }
|
|
|
|
//
|
|
|
|
// But the nested match expression is proved to perform not as well
|
|
|
|
// as series of let's; the first approach does.
|
|
|
|
let pat = self.ecx.pat_tuple(self.fmtsp, pats);
|
2016-06-06 20:22:48 +05:30
|
|
|
let arm = self.ecx.arm(self.fmtsp, vec![pat], args_array);
|
2016-02-08 16:05:05 +01:00
|
|
|
let head = self.ecx.expr(self.fmtsp, ast::ExprKind::Tup(heads));
|
2016-06-06 20:22:48 +05:30
|
|
|
let result = self.ecx.expr_match(self.fmtsp, head, vec![arm]);
|
2014-12-20 21:57:47 +02:00
|
|
|
|
|
|
|
let args_slice = self.ecx.expr_addr_of(self.fmtsp, result);
|
2014-08-25 14:26:18 +01:00
|
|
|
|
2014-12-20 21:57:47 +02:00
|
|
|
// Now create the fmt::Arguments struct with all our locals we created.
|
2014-08-25 14:26:18 +01:00
|
|
|
let (fn_name, fn_args) = if self.all_pieces_simple {
|
std: Stabilize the std::fmt module
This commit performs a final stabilization pass over the std::fmt module,
marking all necessary APIs as stable. One of the more interesting aspects of
this module is that it exposes a good deal of its runtime representation to the
outside world in order for `format_args!` to be able to construct the format
strings. Instead of hacking the compiler to assume that these items are stable,
this commit instead lays out a story for the stabilization and evolution of
these APIs.
There are three primary details used by the `format_args!` macro:
1. `Arguments` - an opaque package of a "compiled format string". This structure
is passed around and the `write` function is the source of truth for
transforming a compiled format string into a string at runtime. This must be
able to be constructed in stable code.
2. `Argument` - an opaque structure representing an argument to a format string.
This is *almost* a trait object as it's just a pointer/function pair, but due
to the function originating from one of many traits, it's not actually a
trait object. Like `Arguments`, this must be constructed from stable code.
3. `fmt::rt` - this module contains the runtime type definitions primarily for
the `rt::Argument` structure. Whenever an argument is formatted with
nonstandard flags, a corresponding `rt::Argument` is generated describing how
the argument is being formatted. This can be used to construct an
`Arguments`.
The primary interface to `std::fmt` is the `Arguments` structure, and as such
this type name is stabilize as-is today. It is expected for libraries to pass
around an `Arguments` structure to represent a pending formatted computation.
The remaining portions are largely "cruft" which would rather not be stabilized,
but due to the stability checks they must be. As a result, almost all pieces
have been renamed to represent that they are "version 1" of the formatting
representation. The theory is that at a later date if we change the
representation of these types we can add new definitions called "version 2" and
corresponding constructors for `Arguments`.
One of the other remaining large questions about the fmt module were how the
pending I/O reform would affect the signatures of methods in the module. Due to
[RFC 526][rfc], however, the writers of fmt are now incompatible with the
writers of io, so this question has largely been solved. As a result the
interfaces are largely stabilized as-is today.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
Specifically, the following changes were made:
* The contents of `fmt::rt` were all moved under `fmt::rt::v1`
* `fmt::rt` is stable
* `fmt::rt::v1` is stable
* `Error` is stable
* `Writer` is stable
* `Writer::write_str` is stable
* `Writer::write_fmt` is stable
* `Formatter` is stable
* `Argument` has been renamed to `ArgumentV1` and is stable
* `ArgumentV1::new` is stable
* `ArgumentV1::from_uint` is stable
* `Arguments::new_v1` is stable (renamed from `new`)
* `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`)
* All formatting traits are now stable, as well as the `fmt` method.
* `fmt::write` is stable
* `fmt::format` is stable
* `Formatter::pad_integral` is stable
* `Formatter::pad` is stable
* `Formatter::write_str` is stable
* `Formatter::write_fmt` is stable
* Some assorted top level items which were only used by `format_args!` were
removed in favor of static functions on `ArgumentV1` as well.
* The formatting-flag-accessing methods remain unstable
Within the contents of the `fmt::rt::v1` module, the following actions were
taken:
* Reexports of all enum variants were removed
* All prefixes on enum variants were removed
* A few miscellaneous enum variants were renamed
* Otherwise all structs, fields, and variants were marked stable.
In addition to these actions in the `std::fmt` module, many implementations of
`Show` and `String` were stabilized as well.
In some other modules:
* `ToString` is now stable
* `ToString::to_string` is now stable
* `Vec` no longer implements `fmt::Writer` (this has moved to `String`)
This is a breaking change due to all of the changes to the `fmt::rt` module, but
this likely will not have much impact on existing programs.
Closes #20661
[breaking-change]
2015-01-13 15:42:53 -08:00
|
|
|
("new_v1", vec![pieces, args_slice])
|
2014-08-25 14:26:18 +01:00
|
|
|
} else {
|
2014-12-19 16:16:16 +02:00
|
|
|
// Build up the static array which will store our precompiled
|
|
|
|
// nonstandard placeholders, if there are any.
|
2017-09-04 13:23:49 +03:00
|
|
|
let fmt = self.ecx.expr_vec_slice(self.macsp, self.pieces);
|
2014-12-19 16:16:16 +02:00
|
|
|
|
std: Stabilize the std::fmt module
This commit performs a final stabilization pass over the std::fmt module,
marking all necessary APIs as stable. One of the more interesting aspects of
this module is that it exposes a good deal of its runtime representation to the
outside world in order for `format_args!` to be able to construct the format
strings. Instead of hacking the compiler to assume that these items are stable,
this commit instead lays out a story for the stabilization and evolution of
these APIs.
There are three primary details used by the `format_args!` macro:
1. `Arguments` - an opaque package of a "compiled format string". This structure
is passed around and the `write` function is the source of truth for
transforming a compiled format string into a string at runtime. This must be
able to be constructed in stable code.
2. `Argument` - an opaque structure representing an argument to a format string.
This is *almost* a trait object as it's just a pointer/function pair, but due
to the function originating from one of many traits, it's not actually a
trait object. Like `Arguments`, this must be constructed from stable code.
3. `fmt::rt` - this module contains the runtime type definitions primarily for
the `rt::Argument` structure. Whenever an argument is formatted with
nonstandard flags, a corresponding `rt::Argument` is generated describing how
the argument is being formatted. This can be used to construct an
`Arguments`.
The primary interface to `std::fmt` is the `Arguments` structure, and as such
this type name is stabilize as-is today. It is expected for libraries to pass
around an `Arguments` structure to represent a pending formatted computation.
The remaining portions are largely "cruft" which would rather not be stabilized,
but due to the stability checks they must be. As a result, almost all pieces
have been renamed to represent that they are "version 1" of the formatting
representation. The theory is that at a later date if we change the
representation of these types we can add new definitions called "version 2" and
corresponding constructors for `Arguments`.
One of the other remaining large questions about the fmt module were how the
pending I/O reform would affect the signatures of methods in the module. Due to
[RFC 526][rfc], however, the writers of fmt are now incompatible with the
writers of io, so this question has largely been solved. As a result the
interfaces are largely stabilized as-is today.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
Specifically, the following changes were made:
* The contents of `fmt::rt` were all moved under `fmt::rt::v1`
* `fmt::rt` is stable
* `fmt::rt::v1` is stable
* `Error` is stable
* `Writer` is stable
* `Writer::write_str` is stable
* `Writer::write_fmt` is stable
* `Formatter` is stable
* `Argument` has been renamed to `ArgumentV1` and is stable
* `ArgumentV1::new` is stable
* `ArgumentV1::from_uint` is stable
* `Arguments::new_v1` is stable (renamed from `new`)
* `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`)
* All formatting traits are now stable, as well as the `fmt` method.
* `fmt::write` is stable
* `fmt::format` is stable
* `Formatter::pad_integral` is stable
* `Formatter::pad` is stable
* `Formatter::write_str` is stable
* `Formatter::write_fmt` is stable
* Some assorted top level items which were only used by `format_args!` were
removed in favor of static functions on `ArgumentV1` as well.
* The formatting-flag-accessing methods remain unstable
Within the contents of the `fmt::rt::v1` module, the following actions were
taken:
* Reexports of all enum variants were removed
* All prefixes on enum variants were removed
* A few miscellaneous enum variants were renamed
* Otherwise all structs, fields, and variants were marked stable.
In addition to these actions in the `std::fmt` module, many implementations of
`Show` and `String` were stabilized as well.
In some other modules:
* `ToString` is now stable
* `ToString::to_string` is now stable
* `Vec` no longer implements `fmt::Writer` (this has moved to `String`)
This is a breaking change due to all of the changes to the `fmt::rt` module, but
this likely will not have much impact on existing programs.
Closes #20661
[breaking-change]
2015-01-13 15:42:53 -08:00
|
|
|
("new_v1_formatted", vec![pieces, args_slice, fmt])
|
2014-08-25 14:26:18 +01:00
|
|
|
};
|
|
|
|
|
2015-07-29 17:01:14 -07:00
|
|
|
let path = self.ecx.std_path(&["fmt", "Arguments", fn_name]);
|
|
|
|
self.ecx.expr_call_global(self.macsp, path, fn_args)
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
|
2016-06-06 20:22:48 +05:30
|
|
|
fn format_arg(ecx: &ExtCtxt,
|
|
|
|
macsp: Span,
|
2017-03-17 04:04:41 +00:00
|
|
|
mut sp: Span,
|
2016-06-06 20:22:48 +05:30
|
|
|
ty: &ArgumentType,
|
2017-03-15 00:22:48 +00:00
|
|
|
arg: ast::Ident)
|
2014-09-13 19:06:01 +03:00
|
|
|
-> P<ast::Expr> {
|
2018-03-18 23:51:53 +03:00
|
|
|
sp = sp.apply_mark(ecx.current_expansion.mark);
|
2017-03-15 00:22:48 +00:00
|
|
|
let arg = ecx.expr_ident(sp, arg);
|
2014-10-31 12:07:13 -05:00
|
|
|
let trait_ = match *ty {
|
2016-05-21 12:58:17 +08:00
|
|
|
Placeholder(ref tyname) => {
|
2015-02-18 14:48:57 -05:00
|
|
|
match &tyname[..] {
|
2016-06-06 20:22:48 +05:30
|
|
|
"" => "Display",
|
2015-01-20 15:45:07 -08:00
|
|
|
"?" => "Debug",
|
2014-10-31 12:07:13 -05:00
|
|
|
"e" => "LowerExp",
|
|
|
|
"E" => "UpperExp",
|
|
|
|
"o" => "Octal",
|
|
|
|
"p" => "Pointer",
|
2014-11-17 11:29:38 -08:00
|
|
|
"b" => "Binary",
|
2014-10-31 12:07:13 -05:00
|
|
|
"x" => "LowerHex",
|
|
|
|
"X" => "UpperHex",
|
2013-07-29 01:12:41 -07:00
|
|
|
_ => {
|
2016-06-06 20:22:48 +05:30
|
|
|
ecx.span_err(sp, &format!("unknown format trait `{}`", *tyname));
|
2014-10-31 12:07:13 -05:00
|
|
|
"Dummy"
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
2013-08-14 20:40:15 -07:00
|
|
|
}
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
2016-05-21 12:58:17 +08:00
|
|
|
Count => {
|
2015-07-29 17:01:14 -07:00
|
|
|
let path = ecx.std_path(&["fmt", "ArgumentV1", "from_usize"]);
|
2016-06-06 20:22:48 +05:30
|
|
|
return ecx.expr_call_global(macsp, path, vec![arg]);
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
2013-08-14 20:40:15 -07:00
|
|
|
};
|
|
|
|
|
2015-07-29 17:01:14 -07:00
|
|
|
let path = ecx.std_path(&["fmt", trait_, "fmt"]);
|
|
|
|
let format_fn = ecx.path_global(sp, path);
|
|
|
|
let path = ecx.std_path(&["fmt", "ArgumentV1", "new"]);
|
|
|
|
ecx.expr_call_global(macsp, path, vec![arg, ecx.expr_path(format_fn)])
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-06 20:22:48 +05:30
|
|
|
pub fn expand_format_args<'cx>(ecx: &'cx mut ExtCtxt,
|
2017-03-28 05:32:43 +00:00
|
|
|
mut sp: Span,
|
2016-06-20 08:49:33 -07:00
|
|
|
tts: &[tokenstream::TokenTree])
|
2018-07-12 11:58:16 +02:00
|
|
|
-> Box<dyn base::MacResult + 'cx> {
|
2018-03-18 23:51:53 +03:00
|
|
|
sp = sp.apply_mark(ecx.current_expansion.mark);
|
2014-12-21 11:28:18 +02:00
|
|
|
match parse_args(ecx, sp, tts) {
|
2016-06-05 20:39:05 +08:00
|
|
|
Some((efmt, args, names)) => {
|
2018-07-19 18:53:26 -07:00
|
|
|
MacEager::expr(expand_preparsed_format_args(ecx, sp, efmt, args, names, false))
|
|
|
|
}
|
|
|
|
None => DummyResult::expr(sp),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn expand_format_args_nl<'cx>(ecx: &'cx mut ExtCtxt,
|
|
|
|
mut sp: Span,
|
|
|
|
tts: &[tokenstream::TokenTree])
|
|
|
|
-> Box<dyn base::MacResult + 'cx> {
|
|
|
|
sp = sp.apply_mark(ecx.current_expansion.mark);
|
|
|
|
match parse_args(ecx, sp, tts) {
|
|
|
|
Some((efmt, args, names)) => {
|
|
|
|
MacEager::expr(expand_preparsed_format_args(ecx, sp, efmt, args, names, true))
|
2014-02-06 08:50:36 +11:00
|
|
|
}
|
2016-06-06 20:22:48 +05:30
|
|
|
None => DummyResult::expr(sp),
|
2014-02-06 08:50:36 +11:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-21 11:28:18 +02:00
|
|
|
/// Take the various parts of `format_args!(efmt, args..., name=names...)`
|
|
|
|
/// and construct the appropriate formatting expression.
|
2016-06-06 20:22:48 +05:30
|
|
|
pub fn expand_preparsed_format_args(ecx: &mut ExtCtxt,
|
|
|
|
sp: Span,
|
2014-09-13 19:06:01 +03:00
|
|
|
efmt: P<ast::Expr>,
|
|
|
|
args: Vec<P<ast::Expr>>,
|
2018-07-19 18:53:26 -07:00
|
|
|
names: HashMap<String, usize>,
|
|
|
|
append_newline: bool)
|
2014-09-13 19:06:01 +03:00
|
|
|
-> P<ast::Expr> {
|
2016-06-02 21:47:34 +08:00
|
|
|
// NOTE: this verbose way of initializing `Vec<Vec<ArgumentType>>` is because
|
|
|
|
// `ArgumentType` does not derive `Clone`.
|
2016-05-14 20:42:47 +08:00
|
|
|
let arg_types: Vec<_> = (0..args.len()).map(|_| Vec::new()).collect();
|
2016-06-02 18:16:24 +08:00
|
|
|
let arg_unique_types: Vec<_> = (0..args.len()).map(|_| Vec::new()).collect();
|
2017-03-28 05:32:43 +00:00
|
|
|
let mut macsp = ecx.call_site();
|
2018-03-18 23:51:53 +03:00
|
|
|
macsp = macsp.apply_mark(ecx.current_expansion.mark);
|
2018-07-14 20:50:30 -07:00
|
|
|
let msg = "format argument must be a string literal";
|
|
|
|
let fmt_sp = efmt.span;
|
2016-09-02 22:01:35 +00:00
|
|
|
let fmt = match expr_to_spanned_string(ecx, efmt, msg) {
|
2018-07-19 18:53:26 -07:00
|
|
|
Ok(mut fmt) if append_newline => {
|
|
|
|
fmt.node.0 = Symbol::intern(&format!("{}\n", fmt.node.0));
|
|
|
|
fmt
|
|
|
|
}
|
2018-07-14 20:50:30 -07:00
|
|
|
Ok(fmt) => fmt,
|
|
|
|
Err(mut err) => {
|
|
|
|
let sugg_fmt = match args.len() {
|
|
|
|
0 => "{}".to_string(),
|
|
|
|
_ => format!("{}{{}}", "{}, ".repeat(args.len())),
|
|
|
|
|
|
|
|
};
|
|
|
|
err.span_suggestion(
|
|
|
|
fmt_sp.shrink_to_lo(),
|
|
|
|
"you might be missing a string literal to format with",
|
|
|
|
format!("\"{}\", ", sugg_fmt),
|
|
|
|
);
|
|
|
|
err.emit();
|
|
|
|
return DummyResult::raw_expr(sp);
|
|
|
|
},
|
2016-09-02 22:01:35 +00:00
|
|
|
};
|
|
|
|
|
2013-07-29 01:12:41 -07:00
|
|
|
let mut cx = Context {
|
2017-08-06 22:54:09 -07:00
|
|
|
ecx,
|
|
|
|
args,
|
|
|
|
arg_types,
|
|
|
|
arg_unique_types,
|
|
|
|
names,
|
2016-05-17 01:02:42 +08:00
|
|
|
curarg: 0,
|
2016-05-14 20:42:47 +08:00
|
|
|
arg_index_map: Vec::new(),
|
2016-05-21 16:00:01 +08:00
|
|
|
count_args: Vec::new(),
|
|
|
|
count_positions: HashMap::new(),
|
|
|
|
count_positions_count: 0,
|
|
|
|
count_args_index_offset: 0,
|
2014-12-20 23:37:25 +02:00
|
|
|
literal: String::new(),
|
2014-02-28 13:09:09 -08:00
|
|
|
pieces: Vec::new(),
|
2014-08-21 14:34:00 +01:00
|
|
|
str_pieces: Vec::new(),
|
2014-08-25 14:26:18 +01:00
|
|
|
all_pieces_simple: true,
|
2017-08-06 22:54:09 -07:00
|
|
|
macsp,
|
2016-09-02 22:01:35 +00:00
|
|
|
fmtsp: fmt.span,
|
2017-11-06 08:49:47 +00:00
|
|
|
invalid_refs: Vec::new(),
|
2014-01-18 01:53:10 +11:00
|
|
|
};
|
2013-07-29 01:12:41 -07:00
|
|
|
|
2016-11-16 10:52:37 +00:00
|
|
|
let fmt_str = &*fmt.node.0.as_str();
|
2018-07-19 23:14:00 -07:00
|
|
|
let mut parser = parse::Parser::new(fmt_str, fmt.node.1);
|
2016-06-05 18:01:37 +08:00
|
|
|
let mut pieces = vec![];
|
2015-02-03 23:31:06 +01:00
|
|
|
|
2018-03-05 15:58:54 -03:00
|
|
|
while let Some(mut piece) = parser.next() {
|
|
|
|
if !parser.errors.is_empty() {
|
|
|
|
break;
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
}
|
2018-03-05 15:58:54 -03:00
|
|
|
cx.verify_piece(&piece);
|
|
|
|
cx.resolve_name_inplace(&mut piece);
|
|
|
|
pieces.push(piece);
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
}
|
2016-06-05 18:01:37 +08:00
|
|
|
|
2017-11-09 17:16:25 +00:00
|
|
|
let numbered_position_args = pieces.iter().any(|arg: &parse::Piece| {
|
|
|
|
match *arg {
|
|
|
|
parse::String(_) => false,
|
|
|
|
parse::NextArgument(arg) => {
|
|
|
|
match arg.position {
|
|
|
|
parse::Position::ArgumentIs(_) => true,
|
|
|
|
_ => false,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2016-05-14 20:42:47 +08:00
|
|
|
cx.build_index_map();
|
|
|
|
|
|
|
|
let mut arg_index_consumed = vec![0usize; cx.arg_index_map.len()];
|
2016-06-05 18:01:37 +08:00
|
|
|
for piece in pieces {
|
2018-05-08 16:10:16 +03:00
|
|
|
if let Some(piece) = cx.build_piece(&piece, &mut arg_index_consumed) {
|
|
|
|
let s = cx.build_literal_string();
|
2016-06-05 18:01:37 +08:00
|
|
|
cx.str_pieces.push(s);
|
|
|
|
cx.pieces.push(piece);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-30 10:51:18 -08:00
|
|
|
if !parser.errors.is_empty() {
|
2018-05-10 09:09:58 -07:00
|
|
|
let err = parser.errors.remove(0);
|
|
|
|
let sp = cx.fmtsp.from_inner_byte_pos(err.start, err.end);
|
|
|
|
let mut e = cx.ecx.struct_span_err(sp, &format!("invalid format string: {}",
|
|
|
|
err.description));
|
|
|
|
e.span_label(sp, err.label + " in format string");
|
|
|
|
if let Some(note) = err.note {
|
2016-11-10 12:48:55 -08:00
|
|
|
e.note(¬e);
|
|
|
|
}
|
|
|
|
e.emit();
|
2014-12-30 10:51:18 -08:00
|
|
|
return DummyResult::raw_expr(sp);
|
Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes #9795
Closes #8968
2014-02-04 19:02:10 -08:00
|
|
|
}
|
2014-08-21 14:34:00 +01:00
|
|
|
if !cx.literal.is_empty() {
|
2018-05-08 16:10:16 +03:00
|
|
|
let s = cx.build_literal_string();
|
2014-08-21 14:34:00 +01:00
|
|
|
cx.str_pieces.push(s);
|
|
|
|
}
|
2013-07-29 01:12:41 -07:00
|
|
|
|
2017-11-06 08:49:47 +00:00
|
|
|
if cx.invalid_refs.len() >= 1 {
|
2017-11-09 17:16:25 +00:00
|
|
|
cx.report_invalid_references(numbered_position_args);
|
2017-11-06 08:49:47 +00:00
|
|
|
}
|
|
|
|
|
2013-07-29 01:12:41 -07:00
|
|
|
// Make sure that all arguments were used and all arguments have types.
|
2016-06-05 20:39:05 +08:00
|
|
|
let num_pos_args = cx.args.len() - cx.names.len();
|
2016-11-11 15:23:15 +11:00
|
|
|
let mut errs = vec![];
|
2013-07-29 01:12:41 -07:00
|
|
|
for (i, ty) in cx.arg_types.iter().enumerate() {
|
2016-05-14 20:42:47 +08:00
|
|
|
if ty.len() == 0 {
|
2016-05-21 16:00:01 +08:00
|
|
|
if cx.count_positions.contains_key(&i) {
|
|
|
|
continue;
|
|
|
|
}
|
2016-06-05 20:39:05 +08:00
|
|
|
let msg = if i >= num_pos_args {
|
|
|
|
// named argument
|
|
|
|
"named argument never used"
|
|
|
|
} else {
|
|
|
|
// positional argument
|
|
|
|
"argument never used"
|
|
|
|
};
|
2016-11-11 15:23:15 +11:00
|
|
|
errs.push((cx.args[i].span, msg));
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|
|
|
|
}
|
2016-11-11 15:23:15 +11:00
|
|
|
if errs.len() > 0 {
|
|
|
|
let args_used = cx.arg_types.len() - errs.len();
|
|
|
|
let args_unused = errs.len();
|
|
|
|
|
|
|
|
let mut diag = {
|
|
|
|
if errs.len() == 1 {
|
|
|
|
let (sp, msg) = errs.into_iter().next().unwrap();
|
|
|
|
cx.ecx.struct_span_err(sp, msg)
|
|
|
|
} else {
|
2018-01-16 18:11:35 -08:00
|
|
|
let mut diag = cx.ecx.struct_span_err(
|
|
|
|
errs.iter().map(|&(sp, _)| sp).collect::<Vec<Span>>(),
|
|
|
|
"multiple unused formatting arguments"
|
|
|
|
);
|
2018-07-14 20:50:30 -07:00
|
|
|
diag.span_label(cx.fmtsp, "multiple missing formatting arguments");
|
2018-01-16 18:11:35 -08:00
|
|
|
diag
|
2016-11-11 15:23:15 +11:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
// Decide if we want to look for foreign formatting directives.
|
|
|
|
if args_used < args_unused {
|
|
|
|
use super::format_foreign as foreign;
|
|
|
|
|
|
|
|
// The set of foreign substitutions we've explained. This prevents spamming the user
|
|
|
|
// with `%d should be written as {}` over and over again.
|
|
|
|
let mut explained = HashSet::new();
|
|
|
|
|
|
|
|
// Used to ensure we only report translations for *one* kind of foreign format.
|
|
|
|
let mut found_foreign = false;
|
|
|
|
|
|
|
|
macro_rules! check_foreign {
|
|
|
|
($kind:ident) => {{
|
|
|
|
let mut show_doc_note = false;
|
|
|
|
|
|
|
|
for sub in foreign::$kind::iter_subs(fmt_str) {
|
|
|
|
let trn = match sub.translate() {
|
|
|
|
Some(trn) => trn,
|
|
|
|
|
|
|
|
// If it has no translation, don't call it out specifically.
|
|
|
|
None => continue,
|
|
|
|
};
|
|
|
|
|
|
|
|
let sub = String::from(sub.as_str());
|
|
|
|
if explained.contains(&sub) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
explained.insert(sub.clone());
|
|
|
|
|
|
|
|
if !found_foreign {
|
|
|
|
found_foreign = true;
|
|
|
|
show_doc_note = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
diag.help(&format!("`{}` should be written as `{}`", sub, trn));
|
|
|
|
}
|
|
|
|
|
|
|
|
if show_doc_note {
|
2018-07-14 20:50:30 -07:00
|
|
|
diag.note(concat!(
|
|
|
|
stringify!($kind),
|
|
|
|
" formatting not supported; see the documentation for `std::fmt`",
|
|
|
|
));
|
2016-11-11 15:23:15 +11:00
|
|
|
}
|
|
|
|
}};
|
|
|
|
}
|
|
|
|
|
|
|
|
check_foreign!(printf);
|
|
|
|
if !found_foreign {
|
|
|
|
check_foreign!(shell);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
diag.emit();
|
|
|
|
}
|
2013-07-29 01:12:41 -07:00
|
|
|
|
2014-12-21 11:28:18 +02:00
|
|
|
cx.into_expr()
|
2013-07-29 01:12:41 -07:00
|
|
|
}
|