format_args! "decompiler": forced warnings and fmt::Arguments::new_v1_formatted "support".

[eddyb]

(Each commit should be reviewed separately)

---

The main "externally" visible change is the "force warnings" one - thought it's still mostly just for us.

Due to Cargo using --cap-lints, you normally can't see warnings in non-local dependencies - and that includes the standard library when using -Zbuild-std (like we do).
So every time the "format_args! decompiler" would fail (e.g. while working on a rustup, before updating it) for a panic! in e.g. core, it would silently cause issues downstream (while making it harder to diagnose)

After this PR, it will always warn in the crate responsible (though hopefully never, for Rust-GPU users).

---

I've had this "force warnings" change around for a while, but never submitted it because there were always a few warnings from core - turns out they were caused by fmt::Arguments::new_v1_formatted, which is used for format_args! with any non-default options (e.g. padding) or non-trivial argument numbering, etc.

I decided to "support" those cases - however, actually extracting the necessary information would be too much effort (and require relying on unstable implementation details of core::fmt::rt), so the debugPrintf form includes all the arguments but in a very general "these N args go into M placeholders somehow".

Also, there's some really hacky skipping of core::fmt::rt::Placeholder::new calls, due to main predating:

• Simplify expansion for format_args!(). rust-lang/rust#139131

Thankfully, that PR landed between 1.87 and 1.88, so #249 (the ~1.88 rustup) should be able to remove the hacks (as the entire &[core::fmt::rt::Placeholder] slice should be a constant then, just like the &[&str] one is).

(In theory, due to the level of simplification done upstream, it may be plausible to start decoding the Placeholder values, but I would not want to put effort into it until an usecase is revealed)

---

There are also some changes that in theory aren't needed before #320 (the ~1.89 rustup), but which I've found invaluable while debugging any changes to the format_args! "decompiler" logic (and which I wish I had done much sooner).

[Firestar99]

One request, doesn't have to be now if it breaks too much of your future commits, but eventually: Could we move the ~500 line format_args! decompiler monster into a separate function to improve readability of call(), like we already do for the other special cases? Potentially even move it to a separate mod, considering how extensive this feature is?

[Firestar99]

I can't fully verify everything, but looks good to me

Also works on my project

[eddyb]

One request, doesn't have to be now if it breaks too much of your future commits, but eventually: Could we move the ~500 line format_args! decompiler monster into a separate function to improve readability of call(), like we already do for the other special cases?

I'll be honest, I don't remember why it wasn't in a separate method. Frankly, I am tired of updating it, so I am mostly trying to keep it in working condition for the next Rust-GPU release, after which it may become feasible to rewrite it as a much nicer SPIR-T pass (at least after the point where function pointers are representable in SPIR-V, even before recursion/indirect-call emulation), which could also take full advantage of "semantic", instead of "syntactic", pattern-matching (e.g. we could re-enable MIR inlining, and probably get a nice speedup in compile times, plus much less messy IR to deal with etc. - because the SPIR-T pass would run after anything like inlining or replacing variables with their contents, and would act more like partial evaluation).