rust should support an extract-method refactoring

I've discussed this partially elsewhere (e.g. here and here, but I think it's probably an important enough consideration that it deserves to be elevated to an independent issue, for independent discussion. @bill-myers originally raised an argument here that I interpret as showing that current rust's dynamic drop semantics are technically incompatible with an automated extract-method refactoring. (I'd love to be proven wrong on this point.) I want to raise this as an explicit issue so that the following can be discussed:

• Can dynamic drop be made compatible with an automated extract-method refactoring?
• If dynamic drop is indeed incompatible with this refactoring, is it possible to modify rust post 1.0, in a backwards-compatible way, so that this refactoring would becomes possible?
• If, as I fear, the answers to the above questions are "no" and "no", is eventual support for this refactoring something that rust considers important?
• If support for this refactoring is important, how can it be achieved?

From the way I've framed this, my position is probably clear: I think supporting advanced tooling for editing rust source code will be highly important to mainstream acceptance of the language down the road, and we might be running out of time to address issues like this, before 1.0's guarantee of backwards compatibility makes solving this issue much more technically challenging. In any event, I hope these concerns can be discussed...

Start by reading the linked discussions in RFCs 239 and 320, then review how the issue frames dynamic drop semantics and automated extract-method refactoring. This is a design discussion rather than an implementation task; done would require a documented decision about compatibility, language changes, or whether the refactoring should be supported.