@@ -80,35 +80,6 @@ impl<'tcx> Visitor<'tcx> for DeduceReadOnly {
80
80
// `f` passes. Note that function arguments are the only situation in which this problem can
81
81
// arise: every other use of `move` in MIR doesn't actually write to the value it moves
82
82
// 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
-
112
83
if let TerminatorKind :: Call { ref args, .. } = terminator. kind {
113
84
for arg in args {
114
85
if let Operand :: Move ( place) = arg. node {
0 commit comments