Pretty print Fn<(..., ...)> trait refs with parentheses (almost) always by compiler-errors · Pull Request #118268 · rust-lang/rust (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation26 Commits2 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

compiler-errors

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

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

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

compiler-errors

@@ -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(),

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.

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.

estebank

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

Choose a reason for hiding this comment

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

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

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.

estebank

estebank

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));
}
}

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?

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 :/

Choose a reason for hiding this comment

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

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.

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.

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.

estebank

estebank

estebank

@compiler-errors

@bors

📌 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

@matthiaskrgr

…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.

This was referenced

Nov 29, 2023

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Nov 29, 2023

@matthiaskrgr

…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

@bors

…iaskrgr

Rollup of 7 pull requests

Successful merges:

Failed merges:

r? @ghost @rustbot modify labels: rollup

@bors

🔒 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

@compiler-errors

@compiler-errors

@bors

📌 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

@matthiaskrgr

…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

@compiler-errors

…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

@compiler-errors

…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.

This was referenced

Dec 5, 2023

bors added a commit to rust-lang-ci/rust that referenced this pull request

Dec 5, 2023

@bors

…mpiler-errors

Rollup of 9 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

bors added a commit to rust-lang-ci/rust that referenced this pull request

Dec 5, 2023

@bors

…mpiler-errors

Rollup of 9 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

bors added a commit to rust-lang-ci/rust that referenced this pull request

Dec 6, 2023

@bors

…mpiler-errors

Rollup of 9 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

bors added a commit to rust-lang-ci/rust that referenced this pull request

Dec 6, 2023

@bors

…mpiler-errors

Rollup of 9 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Dec 6, 2023

@rust-timer

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

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.

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.