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

Unboxed closure types look weird in error messages #19939

Open
ftxqxd opened this issue Dec 16, 2014 · 10 comments
Open

Unboxed closure types look weird in error messages #19939

ftxqxd opened this issue Dec 16, 2014 · 10 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-diagnostics Working group: Diagnostics

Comments

@ftxqxd
Copy link
Contributor

ftxqxd commented Dec 16, 2014

fn main() {
    let x: () = |:| {}; // error: mismatched types: expected `()`, found `closure[<anon>:2:17: 2:23]` (expected (), found closure)
}

It looks like d258d68 might have changed this for debugging purposes, but forgot to change it back.

@bkoropoff
Copy link
Contributor

Since unboxed closure types are anonymous this seems like the only reasonable way to identify them, even if it's a bit noisy.

@ftxqxd
Copy link
Contributor Author

ftxqxd commented Dec 18, 2014

I think it’d be better if it just gave the input/return types in the type string, like closure(int, int) -> int or something. Of course, that still isn’t enough to uniquely distinguish different closure. It could at least look intentional—so something like closure from <anon>:2:17: 2:23 instead.

@kmcallister kmcallister added the A-diagnostics Area: Messages for errors, warnings, and lints label Jan 16, 2015
@kmcallister
Copy link
Contributor

How about a specific closure(int, int) -> int, from <anon>:2:17: 2:23

@steveklabnik
Copy link
Member

Triage: this error has not changed. Updated code:

fn main() {
        let x: () = || {}; 
}

@steveklabnik steveklabnik added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 9, 2017
@Mark-Simulacrum
Copy link
Member

@rust-lang/compiler: Any thoughts here? It looks like changing this might not be all that hard; if I'm following the code correctly the type information is there if we wanted to print it. It could help with debugging closure inference, too, I guess.

@nikomatsakis
Copy link
Contributor

We used to print the type information and removed it. It was sort of confusing, since it's not part of the type. There are also times when the type information is not available (i.e., we may not have inferred all the types yet). I'm not super-keen on how we print now, but I don't know what my preferred option is.

cc @eddyb, who I think removed the type information from the print-outs and might be able to elaborate on why?

@eddyb
Copy link
Member

eddyb commented Jun 2, 2017

@nikomatsakis I don't recall that. Was it ever printed?! How would one even go about that?

@nikomatsakis
Copy link
Contributor

I am 99.5% sure that we used to print the type signature for a closure; I think we went and peeked in various tables to try and extract it. I am not especially keen on doing that again, but I do feel like we have not yet found a "satisfactory" way to print closure types -- I agree that people would probably expect a closure type as something like Ye Olde lambda(u32, u32) -> u32 syntax (probably not with that particular keyword).

@eddyb
Copy link
Member

eddyb commented Jun 5, 2017

Just Use Greek (TM): λ

@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 22, 2017
@estebank
Copy link
Contributor

estebank commented Oct 13, 2017

Some output options:

fn() -> () @ src/main.rs:2:21: 2:26
fn(_) -> _ @ src/main.rs:2:21: 2:26
fn(u32, u32) -> u32 @ src/main.rs:2:21: 2:26
lambda(u32, u32) -> u32 @ src/main.rs:2:21: 2:26
closure fn(u32, u32) -> u32 @ src/main.rs:2:21: 2:26
closure(u32, u32) -> u32 @ src/main.rs:2:21: 2:26
closure fn(u32, u32) -> u32 from src/main.rs:2:21: 2:26
fn(u32, u32) -> u32  # Given that in type errors the found type is always highlighted,
                     # the span for a closure in found type wouldn't need to be displayed.
                     # I don't believe there's a case where a specific closure would
                     # be the expected type.
fn(u32, u32) -> u32 { [src/main.rs:2:21: 2:26] }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-diagnostics Working group: Diagnostics
Projects
None yet
Development

No branches or pull requests

9 participants