[MIR] Handle overloaded call expressions during HIR -> HAIR translation. #30692
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
|
(rust_highfive has picked a reviewer for you, use r? to override) |
| @@ -88,6 +88,19 @@ fn test8() -> isize { | |||
| Two::two() | |||
| } | |||
|
|
|||
| #[rustc_mir(graphviz="method.dot")] | |||
There was a problem hiding this comment.
We do not want graphviz output during tests.
There was a problem hiding this comment.
Whoops, that shouldn't be in there...
|
Overall LGTM. |
michaelwoerister
force-pushed
the
mir-overloaded-fn-calls
branch
from
bc51c40 to
545e9d2
Compare
|
Fixed the graphviz thing. |
| #[rustc_mir] | ||
| fn test_fn_object(f: &Fn(i32, i32) -> i32, x: i32, y: i32) -> i32 { | ||
| f(x, y) | ||
| } |
There was a problem hiding this comment.
shouldn't we write a test that is not for a closure object?
|
r=me with a non-object test as well |
michaelwoerister
force-pushed
the
mir-overloaded-fn-calls
branch
from
545e9d2 to
1f69493
Compare
|
@bors r+ |
|
📌 Commit 1f69493 has been approved by |
…when translating function references.
|
@bors r- |
|
I want to get rid of an unnecessary |
michaelwoerister
force-pushed
the
mir-overloaded-fn-calls
branch
from
1f69493 to
e281509
Compare
|
@bors r=nikomatsakis |
|
📌 Commit e281509 has been approved by |
|
⌛ Testing commit e281509 with merge 8f7e5bb... |
|
💔 Test failed - auto-linux-64-opt |
|
@bors retry |
bors
added a commit
that referenced
this pull request
Jan 6, 2016
…komatsakis So far, calls going through `Fn::call`, `FnMut::call_mut`, or `FnOnce::call_once` have not been translated properly into MIR: The call `f(a, b, c)` where `f: Fn(T1, T2, T3)` would end up in MIR as: ``` call `f` with arguments `a`, `b`, `c` ``` What we really want is: ``` call `Fn::call` with arguments `f`, `a`, `b`, `c` ``` This PR transforms these kinds of overloaded calls during `HIR -> HAIR` translation. What's still a bit funky is that the `Fn` traits expect arguments to be tupled but due to special handling type-checking and trans, we do not actually tuple arguments and everything still checks out fine. So, after this PR we end up with MIR containing calls where function signature and arguments seemingly don't match: ``` call Fn::call(&self, args: (T1, T2, T3)) with arguments `f`, `a`, `b`, `c` ``` instead of ``` call Fn::call(&self, args: (T1, T2, T3)) with arguments `f`, (`a`, `b`, `c`) // <- args tupled! ``` It would be nice if the call traits could go without special handling in MIR and later on.
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.
So far, calls going through
Fn::call,FnMut::call_mut, orFnOnce::call_oncehave not been translated properly into MIR:The call
f(a, b, c)wheref: Fn(T1, T2, T3)would end up in MIR as:What we really want is:
This PR transforms these kinds of overloaded calls during
HIR -> HAIRtranslation.What's still a bit funky is that the
Fntraits expect arguments to be tupled but due to special handling type-checking and trans, we do not actually tuple arguments and everything still checks out fine. So, after this PR we end up with MIR containing calls where function signature and arguments seemingly don't match:instead of
It would be nice if the call traits could go without special handling in MIR and later on.