Nicer printing of type and region variables #2632
Comments
|
this sounds good. I think we ought to just roll these flags together into one though. |
|
So, just to be clear, |
|
conceptually I think we just want one flag for "print types using internal notation". This would affect the printing of regions as well as type variables and so forth. |
|
Agreed. We discussed this at a meeting recently and wanted to get tidied up. Possible relative of #2951 maybe? IIRC the strings |
|
Nominating for milestone 5, production-ready |
|
just a bug, removing milestone/nomination. |
|
visiting for triage, email from 2013 sep 09. |
|
Error messages containing generics were changed in this commit e25d706 regions haven't been changed. Triaged |
|
This bug really needs a test case or two. For type parameters, we current give an error message like code: fn main() { let 1 = 1.0; }And for regions... I don't know how to get one to be printed. |
|
@nikomatsakis are region variables just printed in debug messages? I didn't find a case for that, TBH. @huonw Agreed, I think, as you also mentioned on IRC earlier, that the current format shouldn't be the final format. We could start discussing a better format for that here. My first thought is that we could maybe get rid of |
|
Visiting for triage. Error message @huonw mentioned is still relevant. Still would like some more test cases. |
ghost
mentioned this issue
…atsakis This PR aims to improve the readability of diagnostic messages that involve unresolved type variables. Currently, messages like the following: ```rust mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>` <anon>:6 let a: Result<uint, ()> = None; ^~~~ mismatched types: expected `&mut <generic #2>`, found `uint` <anon>:7 f(42u); ^~~ ``` tend to appear unapproachable to new users. [0] While specific type var IDs are valuable in diagnostics that deal with more than one such variable, in practice many messages only mention one. In those cases, leaving out the specific number makes the messages slightly less terrifying. ```rust mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_>` <anon>:6 let a: Result<uint, ()> = None; ^~~~ mismatched types: expected `&mut _`, found `uint` <anon>:7 f(42u); ^~~ ``` As you can see, I also tweaked the aesthetics slightly by changing type variables to use the type hole syntax _. For integer variables, the syntax used is: ```rust mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1i>` <anon>:6 let a: Result<uint, ()> = Some(1); ``` and float variables: ```rust mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1f>` <anon>:6 let a: Result<uint, ()> = Some(0.5); ``` [0] https://twitter.com/coda/status/517713085465772032 Closes #2632. Closes #3404. Closes #18426.
Today on IRC several of us were talking about how the way that type variables and region variables are printed (
<VN>and<RN>, respectively, whereNis an id number) is rather ugly. Now that we have integral type variables, printing them as<VIN>(as is happening now) just adds insult to injury. "integer" and "unconstrained int" were suggested as nicer solutions for integral type variables. We should come up with something nicer for the others as well.There's already a
-Z ppregionscompiler flag, useful for debugging, that prints the IDs of regions. Maybe there could be a-Z ppvaridsflag that prints the ID numbers for times when we really need them.The text was updated successfully, but these errors were encountered: