Why do you need the temporary? Does this work if the addition doesn't consume a? In that case moving a into a temporary could break code borrowing it later on.

The temporary variable is necessary. Without it, the mutation of first snippet would not compile.

Example (Playground)
We want to transform the expression 1+2. The naive transformation replaces the+ by some form of add function that contains the appropriate information to activate some mutation conditionally. The transformed code would look like add(1,2). However, we know that this fails to typecheck since the first 1 is defaulted to i32. This is known and you proposed the if false trick to fix the problem. The output of the if false for the statement 1+2 trick is if false {1+2} else {add(1,2)}. This does not fix the original problem: The type of the literal 1 is still defaulted to i32. The underlying issue is that the first and second 1 do not have the same type, which was one of the intentions of the if false trick. So I figured that a temporary variable will solve exactly that.

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 a is consumed by the addition, by definition of the Add trait.

I'm on mobile right now, but you can implement Add on references.

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 1 + MutateAdd(..) + 2.

I do like the idea of inserting a custom type in the middle of the add operation. However, this requires to write impl<T> Add<MutagenAdd> for T, which is not allowed due to orphan rules.

Implementing Add on referencs is no issue here. If impl Add for &Foo then, foo + foo would not compile with or without mutation. &foo + &foo works in both cases.

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

I do like the idea of inserting a custom type in the middle of the add operation. However, this requires to write impl<T> Add<MutagenAdd> for T, which is not allowed due to orphan rules.

Well you can manually impl it for all primitives: https://play.rust-lang.org/?gist=132755b74337dc5ca1dd0c7e9179c26b

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. string + "foo" and for custom types.

The more general issue is that the compiler has a special case for type inference in the case of integer expressions. Any expression like MutagenAdd + 1 + 2 or MutagenAdd(1) + 2 will fall short in type inference. The if false approach tricks the compiler to do the special casing for us.

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