metavar explanations are outdated

[Veykril]

The counting order has been inversed recently I believe so the metavar section describes most metavars incorrectly now

[correabuscar]

It's kinda odd how it sees it(there's one \n) (playground):

match (&compute_len("its input should somehow be self-referential, so let us make it return some\nninety-one!"),
            &Some(91)) {
        (left_val, right_val) => {
            if !(*left_val == *right_val) {
                    let kind = ::core::panicking::AssertKind::Eq;
                    ::core::panicking::assert_failed(kind, &*left_val,
                        &*right_val, ::core::option::Option::None);
                }
        }
    };

but in code it's

assert_eq!(
        call_a_or_b_on_tail!(
            (a: compute_len, b: show_tail),
            and now, to justify the existence of two paths
            we will also call a: its input should somehow
            be self-referential, so let us make it return
            some ninety-one!
        ),
        Some(91)
    );

[Veykril]

Oh interesting, the failure is not due tothe metavar changes, hmm wonder what changed there then

[Veykril]

This regressed in rust 1.76, will investigate. Neverheless, the issue here is still applicable, the explanations are outdated since rust-lang/rust#117050

[Veykril]

Right we are relying on the stringify output here which is not really specified so this is bound to occasionally break