Unboxed closure types look weird in error messages

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.

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

   Brian Koropoff at 2014-12-18 03:12:37

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

   Rewi Haar at 2014-12-18 03:30:55

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

   Keegan McAllister at 2015-01-16 18:11:30

4. Triage: this error has not changed. Updated code:

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

   Steve Klabnik at 2016-02-02 16:52:36

5. @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.

   Mark Rousskov at 2017-05-31 19:46:39

6. 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?

   Niko Matsakis at 2017-06-02 17:52:22

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

   Eduard-Mihai Burtescu at 2017-06-02 17:55:26

8. 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).

   Niko Matsakis at 2017-06-05 16:32:18

9. Just Use Greek (TM): λ

   Eduard-Mihai Burtescu at 2017-06-05 18:28:52

10. 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] }
    

    Esteban Kuber at 2017-10-13 01:03:20