Suggested revisions to PR 13676. #1
Merged
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
Most important: distinguish function decl sugar for omitting `-> ()` from type inference on closures. I also tried to add a couple more examples to further emphasize this distinction. Note that this sugar (of omitting `-> ()`) is actually already briefly mentioned in an earlier section, so it is a little tricky deciding whether to put more material here, or to move it up to the previous section. Other drive-by fixes: * Fix the line length of the code blocks to fit in the width provided in the rendered HTML * Some minor revisions to wording (e.g. try to clarify in some cases where a type mismatch is arising).
mdinger
added a commit
that referenced
this pull request
May 1, 2014
Suggested revisions to PR 13676.
mdinger
pushed a commit
that referenced
this pull request
Nov 1, 2014
…ariables Diagnostics such as the following ``` 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 rust-lang#2>`, found `uint` <anon>:7 f(42u); ^~~ ``` tend to be fairly unappealing to new users. 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. In addition, type variables have been changed to use the type hole syntax `_` in diagnostics. With a variable ID, they're printed as `_#id` (e.g. `_#1`). In cases where the ID is left out, it's simply `_`. Integer and float variables have an additional suffix after the number, e.g. `_#1i` or `_#3f`.
mdinger
pushed a commit
that referenced
this pull request
Nov 1, 2014
…, r=nikomatsakis 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 rust-lang#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 rust-lang#2632. Closes rust-lang#3404. Closes rust-lang#18426.
mdinger
pushed a commit
that referenced
this pull request
Jan 2, 2015
Fixes rust-lang#19707. In terms of output, it currently uses the form `argument #1`, `argument rust-lang#2`, etc. If anyone has any better suggestions I would be glad to consider them.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull in pnkfelix's recommendations.