-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid exposing type parameters and implementation details sourced from macro expansions #107789
Conversation
r? @jackh726 (rustbot has picked a reviewer for you, use r? to override) |
Some changes occurred in need_type_info.rs cc @lcnr |
I think the more general fix is to not consider any expressions which are from a macro expansion in the diagnostic here I think the best fix is to change the way we avoid stuff from macro expansions. We currently simply cause the affected source to have a very high cost:
It should be easier to instead completely ignore such sources. This may need a bit of experimentation |
I think Currently experimenting to figure out how to fully block macro expansion sources, because while simply skip updating infer source if it's from a macro expansion works for the error[E0282]: type annotations needed
--> tests/ui/issues/issue-16966.rs:2:12
|
2 | panic!(std::default::Default::default());
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type for type parameter `M` declared on the function `begin_panic` which before skipping infer sources from macro expansions was error[E0282]: type annotations needed
--> $DIR/issue-16966.rs:2:5
|
LL | panic!(std::default::Default::default());
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `M` declared on the function `begin_panic`
|
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info) |
I found out how to cover the
Since apparently if I got rid of the error[E0282]: type annotations needed for `Vec<T>`
--> tests/ui/type/type-check/cannot_infer_local_or_vec.rs:2:9
|
2 | let x = vec![];
| ^
-Ztrack-diagnostics: created at compiler/rustc_infer/src/infer/error_reporting/need_type_info.rs:559:14
|
help: consider giving `x` an explicit type, where the placeholders `_` are specified
|
2 | let x: Vec<T> = vec![];
| ++++++++ whereas previously it was error[E0282]: type annotations needed for `Vec<T>`
--> $DIR/cannot_infer_local_or_vec.rs:2:9
|
LL | let x = vec![];
| ^
|
help: consider giving `x` an explicit type, where the type for type parameter `T` is specified
|
LL | let x: Vec<T> = vec![];
| ++++++++
error: aborting due to previous error |
1ae931e
to
a9c96d5
Compare
hmm, idk 😅 that requires some fiddling around, maybe only use the parameter name and don't explain where it comes from? I think it should be enough to simply not add a parent to the |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
a9c96d5
to
b58347a
Compare
I think I fixed the |
format!()
desugaring when empty array arguments are supplied…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#107789 (Avoid exposing type parameters and implementation details sourced from macro expansions) - rust-lang#107836 (Handle properly when there is no crate attrs) - rust-lang#107839 (avoid duplicating the RUSTC_LOG env var name) - rust-lang#107866 (Allow wasi-libc to initialize its environment variables lazily.) - rust-lang#107876 (create symlink only for non-windows operating systems) - rust-lang#107882 (Cleanup typos in en_US/borrowck.ftl) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
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
gets desugared into (
rustc +nightly --edition=2018 issue-107745.rs -Z unpretty=hir
):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 doesnew_debug
. But since[]
doesn't have an origin for the type parameter definition, it points tonew_debug
instead and leaks the internal implementation detail since all[]
has is an type inference variable.The Bad FixThis 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 anInsertableGenericArg
. 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.