[MIR] Handle overloaded call expressions during HIR -> HAIR translation.#30692
Merged
bors merged 3 commits intorust-lang:masterfrom Jan 6, 2016
Merged
[MIR] Handle overloaded call expressions during HIR -> HAIR translation.#30692bors merged 3 commits intorust-lang:masterfrom
bors merged 3 commits intorust-lang:masterfrom
Conversation
Contributor
|
(rust_highfive has picked a reviewer for you, use r? to override) |
src/test/run-pass/mir_trans_calls.rs
Outdated
Member
There was a problem hiding this comment.
We do not want graphviz output during tests.
Member
Author
There was a problem hiding this comment.
Whoops, that shouldn't be in there...
Member
|
Overall LGTM. |
bc51c40 to
545e9d2
Compare
Member
Author
|
Fixed the graphviz thing. |
Contributor
There was a problem hiding this comment.
shouldn't we write a test that is not for a closure object?
Contributor
|
r=me with a non-object test as well |
545e9d2 to
1f69493
Compare
Contributor
|
@bors r+ |
Collaborator
|
📌 Commit 1f69493 has been approved by |
…when translating function references.
Member
Author
|
@bors r- |
Member
Author
|
I want to get rid of an unnecessary |
1f69493 to
e281509
Compare
Member
Author
|
@bors r=nikomatsakis |
Collaborator
|
📌 Commit e281509 has been approved by |
Collaborator
|
⌛ Testing commit e281509 with merge 8f7e5bb... |
Collaborator
|
💔 Test failed - auto-linux-64-opt |
Member
Author
|
@bors retry |
Collaborator
|
⌛ Testing commit e281509 with merge 7312e0a... |
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.
Collaborator
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
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.