-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
inference improvements #158
Conversation
Why do you need the temporary? Does this work if the addition doesn't consume |
The temporary variable is necessary. Without it, the mutation of first snippet would not compile. Example (Playground) I added some test cases and performed some smoke testing. It seems that the transformation is still valid in the face of non-copy types. Informally, this makes sense since |
I'm on mobile right now, but you can implement |
It just occurred to me that we might create our own type to add. With rebalanced coherence we may be able to make the first example |
I do like the idea of inserting a custom type in the middle of the add operation. However, this requires to write Implementing I suggest merging this approach (which is a slight modification of your original idea). |
I also implemented the approach outlined above to mutators for bit-operations and negation |
Well you can manually impl it for all primitives: https://play.rust-lang.org/?gist=132755b74337dc5ca1dd0c7e9179c26b |
I did not know that. However, the transformation has to be valid for all type combinations, e.g. The more general issue is that the compiler has a special case for type inference in the case of integer expressions. Any expression like |
I would consider this PR ready for merging. I have added some more testcases that show that the improvements fix a all cases I could think of. Hints to any code that still breaks in this new system is welcome. |
Relevant parts of this PR were merged together with #160 |
Fixes #157. The mutation of the snippet given in the issue used to compile but now fails to compile. This PR reverts to the previously use strategy, with slight alterations.
Background
We have 2 functions:
The first snippet did not typecheck correctly in the previous version. This led me to implementing a different approach based on detecting if the left side of an arithmetic operation is a integer literal or derived from some integer literal. This made the first one compile but was not smart enough to detect the second case. I thought I could extend it further, but it turned out that there is not enough information to solve this problem in all cases.
Previously, the trick was to rewrite
a + b
intoif false {a+b} else { <mutator-code>}
.I underestimated the potential of the
if false
trick, which is an error on my part.This PR switches to a modified version of the
if false
trick:a+b
is transformed to{let _tmp = a; if false {_tmp+b} else {<mutator-code based on _tmp and b>}}
. This makes both versions compile and also passed several other test cases.This PR is a work in progress. Feedback is welcome.