Unify closure argument/return types even if kind is not known, deprecate explicit : syntax
#21899
Conversation
This file contains 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
a trait obligation. Partial fix for rust-lang#16440 -- closure return types are not handled yet.
possible. There is some amount of duplication as a result (similar to select) -- I am not happy about this but not sure how to fix it without deeper rewrites.
closure kind, thereby detecting what happens if there are mismatches. Simply removing the `:` annotations caused most of these tests to pass or produce other errors, because the inference would convert the closure into a more appropriate kind. (The ability to override the inference by using the expected type is an important backdoor partly for this reason.)
upgrade the inference based on expected type so that it is able to infer the fn kind in isolation even if the full signature is not available (and we could perhaps do better still in some cases, such as extracting just the types of the arguments but not the return value).
…an the explicit annotation, leading to "extra `mut` declaration" lint errors.
|
@alexcrichton @brson We should stop torturing Travis q_q - surely it's possible to run the tidy script directly. |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this pull request
Feb 4, 2015
This *almost* completes the job for rust-lang#16440. The idea is that even if we do not know whether some closure type `C` implements `Fn` or `FnMut` (etc), we still know its argument and return types. So if we see an obligation `C : Fn(_0)`, we can unify `_0` with those argument types while still considering the obligation ambiguous and unsatisfied. This helps to make a lot of progress with type inference even before closure kind inference is done. As part of this PR, the explicit `:` syntax is removed from the AST and completely ignored. We still infer the closure kind based on the expected type if that is available. There are several reasons for this. First, deciding the closure kind earlier is always better, as it allows us to make more progress. Second, this retains a (admittedly obscure) way for users to manually specify the closure kind, which is useful for writing tests if nothing else. Finally, there are still some cases where inference can fail, so it may be useful to have this manual override. (The expectation is that we will eventually revisit an explicit syntax for specifying the closure kind, but it will not be `:` and may be some sort of generalization of the `||` syntax to handle other traits as well.) This commit does not *quite* fix rust-lang#16640 because a snapshot is still needed to enable the obsolete syntax errors for explicit `&mut:` and friends. r? @eddyb as he reviewed the prior patch in this direction
|
⌛ Testing commit 8ddcb06 with merge a248dd7... |
|
💔 Test failed - auto-linux-64-nopt-t |
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.
This almost completes the job for #16440. The idea is that even if we do not know whether some closure type
CimplementsFnorFnMut(etc), we still know its argument and return types. So if we see an obligationC : Fn(_0), we can unify_0with those argument types while still considering the obligation ambiguous and unsatisfied. This helps to make a lot of progress with type inference even before closure kind inference is done.As part of this PR, the explicit
:syntax is removed from the AST and completely ignored. We still infer the closure kind based on the expected type if that is available. There are several reasons for this. First, deciding the closure kind earlier is always better, as it allows us to make more progress. Second, this retains a (admittedly obscure) way for users to manually specify the closure kind, which is useful for writing tests if nothing else. Finally, there are still some cases where inference can fail, so it may be useful to have this manual override. (The expectation is that we will eventually revisit an explicit syntax for specifying the closure kind, but it will not be:and may be some sort of generalization of the||syntax to handle other traits as well.)This commit does not quite fix #16640 because a snapshot is still needed to enable the obsolete syntax errors for explicit
&mut:and friends.r? @eddyb as he reviewed the prior patch in this direction