Ergonomic format_args!

[xen0n]

Fixes#9456 (at last).

Not a ground-up rewrite of the existing machinery, but more like an added intermediary layer between macro arguments and format placeholders. This is now implementing Rust RFC 1618!

[rust-highfive]

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

[xen0n]

This caused some small regressions here and there. I'll be slowly fixing them; compilation time is very long.

Non-regressions, just TODO:

• compile-fail/ifmt-bad-arg.rs
• run-pass/ifmt.rs

Noticed regressions:

• compile-fail/macro-backtrace-println.rs
• doctest fmt_3 ({:.*} didn't eat the precision argument)

[xen0n]

Implemented correct implicit args handling by resolving all CountIsNextParams and ArgumentNexts into absolute references during parse. Which means, for example, {foo:.*} {} {1:.*} {:.*} {bar:.*} now parses exactly like {foo:.0$} {1} {1:.2$} {4:.3$} {bar:.5$}. Which obviates the need to handle any next-references during expansion and outputting; will remove these later, after I finish up an RFC for this PR later this week.

EDIT: Whoops, CountIsParam(i) should be CountIsNextParam. CountIsParam(i) is also touched but it's not related to resolution (it's expansion).

[aturon]

r? @alexcrichton

[alexcrichton]

Thanks for the PR! I'll take a closer look at this once rust-lang/rfcs#1618 is handled

[xen0n]

Fixed test cases broken by this PR, and added new cases as well.

Currently make check fails on several unrelated tests:

• run-pass/issue-28950.rs
• run-pass/panic-runtime/lto-abort.rs
• run-pass/panic-runtime/lto-unwind.rs
• run-pass/sepcomp-lib-lto.rs

I'm not sure why those keep popping up, it wasn't the case several days ago. Testing master branch right now, will edit this once finished.

Update: master fails on those tests too. Pretty sure these aren't my fault. But again it may be my environment... I have to sleep now though, it's 3 am, too tired to launch yet another investigation.

Another update: I recompiled without --enable-debug and the failures were gone. Surely there is some nasty interaction between LTO and debug code generation. But at least I could sanely continue my work. 😞

[xen0n]

Travis test completed without the unrelated failures, seems there is a pretty-print round-trip failure:

--- pretty.expected.rs 2016-05-22 13:39:14.080831211 +0800+++ pretty.actual.rs 2016-05-22 13:38:56.912831929 +0800@@ -178,7 +178,6 @@
, b = "hijklmn" , c = 3 ) , "abcd hijk 4\nabc hij 3");
t!(format ! ( "{a:.*} {0} {:.*}" , 4 , 3 , "efgh" , a = "abcdef" ) ,
"abcd 4 efg");
-
// Test that pointers don't get truncated.
{
let val = usize::MAX;

Apart from this and deduplication of argument objects, the feature feels almost ready. Waiting for RFC resolution 😄

[alexcrichton]

Ah yeah unfortunately we've had bad luck with debuginfo and LTO in the past (lots of weird LLVM assertions), but thanks for the progress update!

[xen0n]

I immediately gave up fixing the pretty print issue after trying to produce a minimal test case and got this:

macro_rules! t {($a:expr, $b:expr) => { assert_eq!($a, $b)}}pubfnmain(){t!(format!("{:x}{:X}{:x}{:X}{:x}{a:X}",1,2,3,4,5,a=15),"abcdefghijkl");// every time this code gets pretty-printed, a newline is eaten!}

Might as well reduce the length of affected lines, as the bug seems to only occur when a line wrap is needed in the output. I'll finish the argument object de-duplication and then we can start reviewing.

[xen0n]

Rebased and cleaned up a little, should be ready for review!

PS: The reason I think an RFC is really needed, is that some serious documentation changes and maybe deprecation inside the formatting runtime will have to be done. However as the RFC is already submitted and waiting through its FCP this point is already moot.

[alexcrichton]

Can you add a test here as well with side effects on the evaluated expression to ensure it's only calculated once even though it may be formatted multiple times.

[bors]

☔ The latest upstream changes (presumably #34638) made this pull request unmergeable. Please resolve the merge conflicts.

[xen0n]

Rebased again and (finally found time to do so!) added comments to facilitate better understanding. Hope this is not too late for 1.10!

[alexcrichton]

Oops, sorry this fell off the radar! I think this got lost in my inbox by accident...

Ok, everything looks good to me, thanks @xen0n! Could you also squash the commits down? Other than that r=me

[xen0n]

Squashed all review-generated commits into respective commits and rebased again. Also clarified a few _ => panic! cases for better maintainability (no worries if some enum variants got added someday). Should be good to go now! @alexcrichton

(Edit: As for missing 1.10, I was also taking a break from Rust recently so I don't really mind. 😈 )

[alexcrichton]

@bors: r+ 51e54e5

Thanks again!

[bors]

⌛ Testing commit 51e54e5 with merge db71987...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild
Approved by: alexcrichton
Pushing db71987 to master...