Skip to content
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

Pretty print Fn<(..., ...)> trait refs with parentheses (almost) always #118268

Merged
merged 2 commits into from
Dec 6, 2023

Conversation

compiler-errors
Copy link
Member

It's almost always better, at least in diagnostics, to print Fn(i32, u32) instead of Fn<(i32, u32)>.

Related to but doesn't fix #118225. That needs a separate fix.

@rustbot
Copy link
Collaborator

rustbot commented Nov 24, 2023

r? @wesleywiser

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 24, 2023
@rustbot
Copy link
Collaborator

rustbot commented Nov 24, 2023

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@@ -99,7 +99,7 @@ impl<'tcx> LateLintPass<'tcx> for FutureNotSend {
db.note(format!(
"`{}` doesn't implement `{}`",
trait_pred.self_ty(),
trait_pred.trait_ref.print_only_trait_path(),
trait_pred.trait_ref.print_trait_sugared(),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this doesn't matter -- can revert. I actually don't even know why this uses print_only_trait_path, given that it's always Send.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's likely copy-pasted from a more general rustc error.

@bors

This comment was marked as outdated.

"ambiguous `{assoc_name}` from `{}`",
bound.print_only_trait_path(),
),
format!("ambiguous `{assoc_name}` from `{}`", bound.print_trait_sugared(),),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
format!("ambiguous `{assoc_name}` from `{}`", bound.print_trait_sugared(),),
format!("ambiguous `{assoc_name}` from `{}`", bound.print_trait_sugared()),

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a lot of these :(

I ctrl+f'd for ,); and ,), yesterday and found like >50 instances.

Comment on lines +2873 to +2889
TraitRefPrintSugared<'tcx> {
if !with_no_queries()
&& let Some(kind) = cx.tcx().fn_trait_kind_from_def_id(self.0.def_id)
&& let ty::Tuple(args) = self.0.args.type_at(1).kind()
{
p!(write("{}", kind.as_str()), "(");
for (i, arg) in args.iter().enumerate() {
if i > 0 {
p!(", ");
}
p!(print(arg));
}
p!(")");
} else {
p!(print_def_path(self.0.def_id, self.0.args));
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will never print the Output, is that ok?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no Output that we have access to, unfortunately :/

Copy link
Contributor

@estebank estebank Nov 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't we hack something together for Future::Output somewhere?

Edit: I think I was thinking of pretty_print_opaque_impl_type.

Copy link
Member Author

@compiler-errors compiler-errors Nov 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I could eagerly look into the self type and see if it's something with a signature, but it's not always going to be possible. Let me see.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you manage it, great. If not, r=me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, when we extract this information from the self type, it's often not right. For example, when we have:

fn test<F: Fn(u32) -> u32>() {}

test(|_: i32| -> i32 { 0 });

Extracting the return type from the self type will give us an error message mentioning something like {closure}: Fn(u32) -> i32, not Fn(u32) -> u32.

@compiler-errors
Copy link
Member Author

@bors r=estebank

@bors
Copy link
Contributor

bors commented Nov 28, 2023

📌 Commit ecccf33 has been approved by estebank

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 28, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 29, 2023
…tebank

Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always

It's almost always better, at least in diagnostics, to print `Fn(i32, u32)` instead of `Fn<(i32, u32)>`.

Related to but doesn't fix rust-lang#118225. That needs a separate fix.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 29, 2023
…tebank

Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always

It's almost always better, at least in diagnostics, to print `Fn(i32, u32)` instead of `Fn<(i32, u32)>`.

Related to but doesn't fix rust-lang#118225. That needs a separate fix.
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 29, 2023
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#118157 (Add `never_patterns` feature gate)
 - rust-lang#118191 (Suggest `let` or `==` on typo'd let-chain)
 - rust-lang#118231 (also add is_empty to const raw slices)
 - rust-lang#118333 (Print list of missing target features when calling a function with target features outside an unsafe block)
 - rust-lang#118426 (ConstProp: Correctly remove const if unknown value assigned to it.)
 - rust-lang#118428 (rustdoc: Move `AssocItemRender` and `RenderMode` to `html::render`.)
 - rust-lang#118438 (Update nto-qnx.md)

Failed merges:

 - rust-lang#118268 (Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors
Copy link
Contributor

bors commented Nov 29, 2023

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout pretty-print (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self pretty-print --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
Auto-merging compiler/rustc_middle/src/ty/print/pretty.rs
Auto-merging compiler/rustc_infer/src/infer/error_reporting/mod.rs
CONFLICT (content): Merge conflict in compiler/rustc_infer/src/infer/error_reporting/mod.rs
Auto-merging compiler/rustc_hir_analysis/src/astconv/mod.rs
Automatic merge failed; fix conflicts and then commit the result.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 29, 2023
@compiler-errors
Copy link
Member Author

@bors r=estebank

@bors
Copy link
Contributor

bors commented Dec 5, 2023

📌 Commit f6c30b3 has been approved by estebank

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 5, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 5, 2023
…tebank

Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always

It's almost always better, at least in diagnostics, to print `Fn(i32, u32)` instead of `Fn<(i32, u32)>`.

Related to but doesn't fix rust-lang#118225. That needs a separate fix.
compiler-errors added a commit to compiler-errors/rust that referenced this pull request Dec 5, 2023
…tebank

Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always

It's almost always better, at least in diagnostics, to print `Fn(i32, u32)` instead of `Fn<(i32, u32)>`.

Related to but doesn't fix rust-lang#118225. That needs a separate fix.
compiler-errors added a commit to compiler-errors/rust that referenced this pull request Dec 5, 2023
…tebank

Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always

It's almost always better, at least in diagnostics, to print `Fn(i32, u32)` instead of `Fn<(i32, u32)>`.

Related to but doesn't fix rust-lang#118225. That needs a separate fix.
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 5, 2023
…mpiler-errors

Rollup of 9 pull requests

Successful merges:

 - rust-lang#117793 (Update variable name to fix `unused_variables` warning)
 - rust-lang#118123 (Add support for making lib features internal)
 - rust-lang#118268 (Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always)
 - rust-lang#118346 (Add `deeply_normalize_for_diagnostics`, use it in coherence)
 - rust-lang#118350 (Simplify Default for tuples)
 - rust-lang#118450 (Use OnceCell in cell module documentation)
 - rust-lang#118585 (Fix parser ICE when recovering `dyn`/`impl` after `for<...>`)
 - rust-lang#118587 (Cleanup error handlers some more)
 - rust-lang#118642 (bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 5, 2023
…mpiler-errors

Rollup of 9 pull requests

Successful merges:

 - rust-lang#117793 (Update variable name to fix `unused_variables` warning)
 - rust-lang#118123 (Add support for making lib features internal)
 - rust-lang#118268 (Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always)
 - rust-lang#118346 (Add `deeply_normalize_for_diagnostics`, use it in coherence)
 - rust-lang#118350 (Simplify Default for tuples)
 - rust-lang#118450 (Use OnceCell in cell module documentation)
 - rust-lang#118585 (Fix parser ICE when recovering `dyn`/`impl` after `for<...>`)
 - rust-lang#118587 (Cleanup error handlers some more)
 - rust-lang#118642 (bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 6, 2023
…mpiler-errors

Rollup of 9 pull requests

Successful merges:

 - rust-lang#117793 (Update variable name to fix `unused_variables` warning)
 - rust-lang#118123 (Add support for making lib features internal)
 - rust-lang#118268 (Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always)
 - rust-lang#118346 (Add `deeply_normalize_for_diagnostics`, use it in coherence)
 - rust-lang#118350 (Simplify Default for tuples)
 - rust-lang#118450 (Use OnceCell in cell module documentation)
 - rust-lang#118585 (Fix parser ICE when recovering `dyn`/`impl` after `for<...>`)
 - rust-lang#118587 (Cleanup error handlers some more)
 - rust-lang#118642 (bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 6, 2023
…mpiler-errors

Rollup of 9 pull requests

Successful merges:

 - rust-lang#117793 (Update variable name to fix `unused_variables` warning)
 - rust-lang#118123 (Add support for making lib features internal)
 - rust-lang#118268 (Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always)
 - rust-lang#118346 (Add `deeply_normalize_for_diagnostics`, use it in coherence)
 - rust-lang#118350 (Simplify Default for tuples)
 - rust-lang#118450 (Use OnceCell in cell module documentation)
 - rust-lang#118585 (Fix parser ICE when recovering `dyn`/`impl` after `for<...>`)
 - rust-lang#118587 (Cleanup error handlers some more)
 - rust-lang#118642 (bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit ad23f30 into rust-lang:master Dec 6, 2023
11 checks passed
@rustbot rustbot added this to the 1.76.0 milestone Dec 6, 2023
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Dec 6, 2023
Rollup merge of rust-lang#118268 - compiler-errors:pretty-print, r=estebank

Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always

It's almost always better, at least in diagnostics, to print `Fn(i32, u32)` instead of `Fn<(i32, u32)>`.

Related to but doesn't fix rust-lang#118225. That needs a separate fix.
@fmease
Copy link
Member

fmease commented Dec 10, 2023

Actually, I wonder if we should print Fn<(…,)> as Fn(…,) -> _ instead of Fn(…,) since that's closer to its actual meaning. The latter (which this PR has implemented) looks like Fn<(…,), Output = ()> to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incorrect syntax when suggesting the use of Fn* traits as supertraits
6 participants