Rollup merge of #107789 - jieyouxu:issue-107745, r=lcnr

Avoid exposing type parameters and implementation details sourced from macro expansions

Fixes #107745.

~~I would like to **request some guidance** for this issue, because I don't think this is a good fix (a band-aid at best).~~

### The Problem

The code

```rust
fn main() {
    println!("{:?}", []);
}
```

gets desugared into (`rustc +nightly --edition=2018 issue-107745.rs -Z unpretty=hir`):

```rust
#[prelude_import]
use std::prelude::rust_2018::*;
#[macro_use]
extern crate std;
fn main() {
        {
                ::std::io::_print(<#[lang = "format_arguments"]>::new_v1(&["",
                                    "\n"], &[<#[lang = "format_argument"]>::new_debug(&[])]));
            };
    }
```

so the diagnostics code tries to be as specific and helpful as possible, and I think it finds that `[]` needs a type parameter and so does `new_debug`. But since `[]` doesn't have an origin for the type parameter definition, it points to `new_debug` instead and leaks the internal implementation detail since all `[]` has is an type inference variable.

### ~~The Bad Fix~~

~~This PR currently tries to fix the problem by bypassing the generated function `<#[lang = "format_argument"]>::new_debug` to avoid its generic parameter (I think it is auto-generated from the argument `[_; 0]`?) from getting collected as an `InsertableGenericArg`. This is problematic because it also prevents the help from getting displayed.~~

~~I think this fix is not ideal and hard-codes the format generated code pattern, but I can't think of a better fix. I have tried asking on Zulip but no responses there yet.~~

0 files changed, 0 insertions, 0 deletions