@@ -80,35 +80,6 @@ impl<'tcx> Visitor<'tcx> for DeduceReadOnly {
8080 // `f` passes. Note that function arguments are the only situation in which this problem can
8181 // arise: every other use of `move` in MIR doesn't actually write to the value it moves
8282 // from.
83- //
84- // Anyway, right now this situation doesn't actually arise in practice. Instead, the MIR for
85- // that function looks like this:
86- //
87- // fn f(_1: BigStruct) -> () {
88- // let mut _0: ();
89- // let mut _2: BigStruct;
90- // bb0: {
91- // _2 = move _1;
92- // _0 = g(move _2) -> bb1;
93- // }
94- // ...
95- // }
96- //
97- // Because of that extra move that MIR construction inserts, `x` (i.e. `_1`) can *in
98- // practice* safely be marked `readonly`.
99- //
100- // To handle the possibility that other optimizations (for example, destination propagation)
101- // might someday generate MIR like the first example above, we panic upon seeing an argument
102- // to *our* function that is directly moved into *another* function as an argument. Having
103- // eliminated that problematic case, we can safely treat moves as copies in this analysis.
104- //
105- // In the future, if MIR optimizations cause arguments of a caller to be directly moved into
106- // the argument of a callee, we can just add that argument to `mutated_args` instead of
107- // panicking.
108- //
109- // Note that, because the problematic MIR is never actually generated, we can't add a test
110- // case for this.
111-
11283 if let TerminatorKind :: Call { ref args, .. } = terminator. kind {
11384 for arg in args {
11485 if let Operand :: Move ( place) = arg. node {
0 commit comments