dc7559b599
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.~~ |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||