Rust: 借用スコープは必ずしも字句である必要はありません

プロダクションレディにノミネート

私はこれを明確に定義された、または後方互換と呼びます。

ジャックの例

[09:57:06]https://github.com/mozilla/servo/blob/master/src/components/servo/layout/box_builder.rs#L387 -L411
[10:02:06]https://github.com/mozilla/servo/pull/435

コードは再編成されましたが、これが私がしなければならなかった借用チェッカーの特定の緩和策です：

https://github.com/metajack/servo/commit/5324cabbf8757fa68b1aa36548b992041be94ef9

https://github.com/metajack/servo/commit/7234635aa580c8a821003882e77d8e043d247687

いくつかの議論の後、ここでの本当の問題は、借用チェッカーがエイリアスを追跡する努力をせず、借用が範囲外になる時期を決定するために常に地域システムに依存していることです。 最初に対処したい未解決の問題が他にもたくさんあり、変更するとボローチェッカーが大幅に変更されるため、少なくとも短期的にはこれを変更することには消極的です。 別の関連する例とやや詳細な説明については、問題＃6613を参照してください。

エラーメッセージを改善して、何が起こっているのかをより明確にすることができるでしょうか。 字句スコープは比較的理解しやすいですが、私が偶然見つけたこの問題の例では、何が起こっているのかは決して明白ではありませんでした。

単なるバグであり、マイルストーン/ノミネートを削除します。

遠い将来のマイルストーンのために受け入れられました

トリアージバンプ

私はこれを修正するための最良の方法についていくつか考えてきました。 私の基本的な計画は、値がいつ「エスケープ」するかという概念を持つことです。 その概念を形式化するには、いくらかの作業が必要です。 基本的に、借用したポインタが作成されると、それがエスケープされたかどうかを追跡します。 ポインターが死んでいるとき、それが逃げていなければ、これはローンを殺すと見なすことができます。 この基本的な考え方は、「let p =＆...; use-pa-bit-but-never-again; expect-loan-to-be-expired-here;」のような場合をカバーしています。 分析の一部は、借用されたポインターを含む戻り値がまだエスケープされていないと見なすことができる場合を示すルールになります。 これは、「match table.find（...）{... None => {expect-table-not-to-be-loaned-here;}}」のような場合をカバーします。

もちろん、これらすべての中で最も興味深い部分は、エスケープルールです。 ルールは、関数の正式な定義を考慮に入れる必要があると思います。特に、有効期間が私たちに与える知識を利用するために。 たとえば、ほとんどのエスケープ分析では、 foo(p)ような呼び出しが見つかった場合、ポインタpをエスケープと見なします。 しかし、必ずしもそうする必要はありません。 関数が次のように宣言された場合：

fn foo<'a>(x: &'a T) { ... }

実際、 fooは、ライフタイムaより長くpを保持しないことがわかります。 ただし、 barような関数は、エスケープと見なす必要があります。

fn bar<'a>(x: &'a T, y: &mut &'a T)

したがって、おそらくエスケープルールは、バインドされたライフタイムが可変の場所に表示されるかどうかを考慮する必要があります。 これは事実上、タイプベースのエイリアス分析の形式です。 同様の理由が関数の戻り値にも当てはまると思います。 したがって、 findは、エスケープされていない結果を返すと見なす必要があります。

fn find<'a>(&'a self, k: &K) -> Option<&'a V>

ここでの理由は、 'aがfindにバインドされているため、 SelfまたはKタイプのパラメーターに表示できないためです。それらに保存され、変更可能な場所には表示されません。 （現在使用されているものと同じ推論アルゴリズムを適用できます。これは、ライフタイムが変更可能な場所に表示されるかどうかを示すために、＃3598の修正の一部として使用されます）

これについて考える別の方法は、ローンが_早期に期限切れになるということではなく、ローンの範囲が（通常）借用された_変数_に関連付けられて開始され、全期間ではなく、変数が有効期間全体に昇格される場合のみです。 _escapes_。

再借用は少し複雑ですが、さまざまな方法で処理できます。 再借用とは、借用したポインターの内容を借用することです。コンパイラーがほとんどすべてのメソッド呼び出しに自動的に挿入するため、借用は常に発生します。 借用したポインタlet p = &vとlet q = &*pような再借用について考えてみます。 qが死んだときに、もう一度p使用できればいいのですが、 pとq両方が死んだ場合は、再びv （ pもqエスケープしないと仮定）。 ここでの複雑さは、 qがエスケープされた場合、 q有効期間が切れるまで、 pがエスケープされたと見なされる必要があることです。 つまり、コンパイラのノートこと：しかし、私は、この私たちが今日それを処理する方法から_somewhat_自然に落ちると思いますq借りたp （最初は）寿命「Q」（あるが、用を変数自体の）そしてqがエスケープする必要がある場合、それは完全なレキシカルライフタイムにプロモートされます。 トリッキーな部分はデータフローにあると思います。キルを挿入する場所を知っています。 pが再借用された場合、 pのキルをすぐに挿入することはできません。 まあ、私はこれにもっと時間を無駄にすることはありません、それは実行可能であるようです、そして最悪の場合、一般的な状況に適したより簡単な解決策があります（例えば、 pが生涯にわたって逃げたと考えてくださいqローンが逃げるかどうかに関係なく、 q ）。

とにかく、もっと考える必要がありますが、私はこれがどのように機能するかを見始めています。 ＃2202と＃8624が修正されるまで、このような拡張機能に着手するのはまだ気が進まない。これらは、borrowckの2つの既知の問題である。 また、システムの拡張に取り掛かる前に、健全性の証明についてさらに進展させたいと思います。 タイムラインにある他の拡張子は＃6268です。

私はこのバグに遭遇したと思います。 私のユースケースと回避策の試み：

https://gist.github.com/toffaletti/6770126

このバグの別の例を次に示します（私は思います）：

use std::util;

enum List<T> {
    Cons(T, ~List<T>),
    Nil
}

fn find_mut<'a,T>(prev: &'a mut ~List<T>, pred: |&T| -> bool) -> Option<&'a mut ~List<T>> {
    match prev {
        &~Cons(ref x, _) if pred(x) => {}, // NB: can't return Some(prev) here
        &~Cons(_, ref mut rs) => return find_mut(rs, pred),
        &~Nil => return None
    };
    return Some(prev)
}

私は書きたいです：

fn find_mut<'a,T>(prev: &'a mut ~List<T>, pred: |&T| -> bool) -> Option<&'a mut ~List<T>> {
    match prev {
        &~Cons(ref x, _) if pred(x) => return Some(prev),
        &~Cons(_, ref mut rs) => return find_mut(rs, pred),
        &~Nil => return None
    }
}

x借用は、述語の評価が終了するとすぐに無効になると推論しますが、もちろん、借用は現在、試合全体に適用されます。

私はこれをどのようにコーディングするかについてもっと考えました。 私の基本的な計画は、ローンごとに、エスケープされたバージョンとエスケープされていないバージョンの2つのビットがあるということです。 最初に、エスケープされていないバージョンを追加します。 参照がエスケープするとき、エスケープされたビットを追加します。 変数（または一時的なものなど）が機能しなくなった場合、エスケープされていないビットを強制終了しますが、エスケープされたビット（設定されている場合）はそのままにしておきます。 これはすべての主要な例をカバーしていると思います。

cc @ flaper87

この問題はこれをカバーしていますか？

use std::io::{MemReader, EndOfFile, IoResult};

fn read_block<'a>(r: &mut Reader, buf: &'a mut [u8]) -> IoResult<&'a [u8]> {
    match r.read(buf) {
        Ok(len) => Ok(buf.slice_to(len)),
        Err(err) => {
            if err.kind == EndOfFile {
                Ok(buf.slice_to(0))
            } else {
                Err(err)
            }
        }
    }
}

fn main() {
    let mut buf = [0u8, ..2];
    let mut reader = MemReader::new(~[67u8, ..10]);
    let mut block = read_block(&mut reader, buf);
    loop {
        //process block
        block = read_block(&mut reader, buf); //error here
}

cc me

＃9113の良い例

cc me

誤解される可能性がありますが、次のコードもこのバグにぶつかっているようです。

struct MyThing<'r> {
  int_ref: &'r int,
  val: int
}

impl<'r> MyThing<'r> {
  fn new(int_ref: &'r int, val: int) -> MyThing<'r> {
    MyThing {
      int_ref: int_ref,
      val: val
    }
  }

  fn set_val(&'r mut self, val: int) {
    self.val = val;
  }
}


fn main() {
  let to_ref = 10;
  let mut thing = MyThing::new(&to_ref, 30);
  thing.set_val(50);

  println!("{}", thing.val);
}

理想的には、set_valの呼び出しによって引き起こされた可変ボローは、関数が戻るとすぐに終了します。 構造体（および関連するコード）から「int_ref」フィールドを削除すると、問題が解決することに注意してください。 動作に一貫性がありません。

@SergioBenitez同じ問題ではないと思います。 &mut self参照の存続期間が構造体の存続期間と同じであることを明示的に要求しています。

ただし、これを行う必要はありません。 set_val()ライフタイムはまったく必要ありません。

fn set_val(&mut self, val: int) {
    self.val = val;
}

修正するのがかなり難しい別のケースを見つけました：

/// A buffer which breaks chunks only after the specified boundary
/// sequence, or at the end of a file, but nowhere else.
pub struct ChunkBuffer<'a, T: Buffer+'a> {
    input:  &'a mut T,
    boundary: Vec<u8>,
    buffer: Vec<u8>
}

impl<'a, T: Buffer+'a> ChunkBuffer<'a,T> {
    // Called internally to make `buffer` valid.  This is where all our
    // evil magic lives.
    fn top_up<'b>(&'b mut self) -> IoResult<&'b [u8]> {
        // ...
    }
}

impl<'a,T: Buffer+'a> Buffer for ChunkBuffer<'a,T> {
    fn fill_buf<'a>(&'a mut self) -> IoResult<&'a [u8]> {
        if self.buffer.as_slice().contains_slice(self.boundary.as_slice()) {
            // Exit 1: Valid data in our local buffer.
            Ok(self.buffer.as_slice())
        } else if self.buffer.len() > 0 {
            // Exit 2: Add some more data to our local buffer so that it's
            // valid (see invariants for top_up).
            self.top_up()
        } else {
            {
                // Exit 3: Exit on error.
                let read = try!(self.input.fill_buf());
                if read.contains_slice(self.boundary.as_slice()) {
                    // Exit 4: Valid input from self.input. Yay!
                    return Ok(read)
                }
            }
            // Exit 5: Accumulate sufficient data in our local buffer (see
            // invariants for top_up).
            self.top_up()
        }
    }

…それは与える：

/path/to/mylib/src/buffer.rs:168:13: 168:17 error: cannot borrow `*self` as mutable more than once at a time
/path/to/mylib/src/buffer.rs:168             self.top_up()
                                                        ^~~~
/path/to/mylib/src/buffer.rs:160:33: 160:43 note: previous borrow of `*self.input` occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `*self.input` until the borrow ends
/path/to/mylib/src/buffer.rs:160                 let read = try!(self.input.fill_buf());
                                                                            ^~~~~~~~~~
<std macros>:1:1: 3:2 note: in expansion of try!
/path/to/mylib/src/buffer.rs:160:28: 160:56 note: expansion site
/path/to/mylib/src/buffer.rs:170:6: 170:6 note: previous borrow ends here
/path/to/mylib/src/buffer.rs:149     fn fill_buf<'a>(&'a mut self) -> IoResult<&'a [u8]> {
...
/path/to/mylib/src/buffer.rs:170     }

これは基本的に＃12147と同等です。 変数readは内部スコープに埋め込まれていますが、 returnはreadの存続期間を関数全体の存続期間にバインドします。 明らかな回避策のほとんどは失敗します：

1. input.fill_buf 2回呼び出すことはできません。これは、 Bufferインターフェイスが、2回目に検証したばかりのデータを返すことを保証しないためです。 これを試してみると、コードは技術的に正しくありませんが、タイプチェッカーは問題なく合格します。
2. top_upについてはあまりできません。これは、すべてを複雑な方法で変更する必要がある邪悪なコードだからです。
3. 問題のあるbi​​nd + test + returnを別の関数に移動することはできません。これは、新しいAPIでも同じ問題が発生するためです（ if letバインドをテストできる場合を除く）。

'a制約は、理想的にはreadまで完全に伝播されるべきではないように感じます。 しかし、私はここで頭を抱えています。 次にif letを試してみます。

ええと、 if letは昨夜ビルドに組み込まれませんmatchと同じように失敗する可能性があります（私はこれを実行しました）ここでも試してみました）。

unsafeを使用する以外に、どのように進めるかわかりません。

ここでの私の現在のハックは次のようになります。

impl<'a,T: Buffer+'a> Buffer for ChunkBuffer<'a,T> {
    fn fill_buf<'a>(&'a mut self) -> IoResult<&'a [u8]> {
        // ...

            { // Block A.
                let read_or_err = self.input.fill_buf();
                match read_or_err {
                    Err(err) => { return Err(err); }
                    Ok(read) => {
                        if read.contains_slice(self.boundary.as_slice()) {
                               return Ok(unsafe { transmute(read) });
                        }
                    }
                }
            }
            self.top_up()

ここでの理論は、 read （ self.inputにバインドされていた）のライフタイムを削除し、 readを所有するself.input selfに基づいて新しいライフタイムをすぐに適用するというものです。 self.input 。 理想的には、 readの字句の有効期間をブロックAと等しくし、 returnに渡したからといって、それが_lexical_ブロックレベルまで引き上げられないようにします。 明らかに、ライフタイムチェッカーは結果が'aと互換性のあるライフタイムを持っていることを証明する必要がありますが、それがLIFETIME（ read ）をLIFETIME（ 'a ）。

私が大いに混乱している、または私のコードがひどく安全でない可能性は十分にあります。 :-)しかし、私がreturn self.input.fill_buf()をまったく問題なく呼び出すことができるという理由だけで、これはうまくいくはずだと感じています。 その直感を形式化する方法はありますか？

@emkなので、これはSEME領域（つまり、非字句領域）が修正しない「ハードコード」であり、少なくともそれ自体では修正されません。 コンパイラでうまく修正する方法についていくつかのアイデアがありますが、これはSEME領域の重要な拡張です。 通常、コードを再構築することでこれを回避する方法があります。 私がそれをいじって、良い例を生み出すことができるかどうか見てみましょう。

これが1.0で再検討されているかどうか知りたいのですが。 これは最近_lot_に出てきており、1.0が急いで注目を集めると、これが紙切れから肉の傷に跳ね上がるのではないかと心配しています。 Rustの最も目立ち、話題になっている機能として、借用が洗練されて使用可能であることが非常に重要です。

このためのRFCに時間枠はありますか？

@nikomatsakis役立つ場合は、

use std::collections::SmallIntMap;

enum Foo<'a>{ A(&'a mut SmallIntMap<uint>), B(&'a mut uint) }

fn main() {
    let mut map = SmallIntMap::<uint>::new();
    do_stuff(&mut map);
}

fn do_stuff(map: &mut SmallIntMap<uint>) -> Foo {
    match map.find_mut(&1) {
        None => {},  // Definitely can't return A here because of lexical scopes
        Some(val) => return B(val),
    }
    return A(map); // ERROR: borrowed at find_mut???
}

ベビーサークル

@bstrie @pcwaltonと@zwarichはどちらも、この作業を実際に実装しようと時間を費やしました（RFCが密接に関連している可能性があります）。 彼らは予想外の複雑さに遭遇しました。これは、予想よりもはるかに多くの作業が必要になることを意味します。 これらの制限は重要であり、言語の第一印象に影響を与える可能性があることは誰もが同意すると思いますが、すでにスケジュールされている後方互換性のない変更とのバランスを取るのは困難です。

https://github.com/rust-lang/rfcs/pull/396

これが1.0で解決されない場合、この問題がボローチェックAFAIKで本質的に解決できない問題ではない場合、それは人々がボローチェックアプローチを完全に非難するようなものだと思います。

@blaenk借用チェッカーのせいにしないのは難しいです、私は毎日これと同様のもの（@Gankroのような）に遭遇しました。 通常の解決策が旋回（回避策など）/またはコードをより「不変」で機能的なものに再構築するためのコメントである場合、イライラします。

@mtanskiええ、でも欠点は借用チェッカーAFAIKにあります、それを非難するのは間違いではありません。 私が言及しているのは、それがかなり陰湿な借用チェック_アプローチ_とAFAIKの誤った信念に固有の、根本的な、解決できない問題であると新参者に信じさせるかもしれないということです。

場合：「p =＆...; use-pa-bit-but-never-again; expect-loan-to-be-expired-here;」 今のところ、その借用のスコープの終了を手動で宣言するkill（p）命令は許容できると思います。 それ以降のバージョンでは、この命令が不要な場合は単に無視するか、pの再利用が検出された場合はエラーとしてフラグを立てることができます。

/* (wanted) */
/*
fn main() {

    let mut x = 10;

    let y = &mut x;

    println!("x={}, y={}", x, *y);

    *y = 11;

    println!("x={}, y={}", x, *y);
}
*/

/* had to */
fn main() {

    let mut x = 10;
    {
        let y = &x;

        println!("x={}, y={}", x, *y);
    }

    {
        let y = &mut x;

        *y = 11;
    }

    let y = &x;

    println!("x={}, y={}", x, *y);
}

それを行うプレリュードにはdrop（）メソッドがあります。 しかし、そうではないようです
変更可能な借用を支援します。

日、2015年4月5日には、13:41のaxeothの[email protected]は書きました：

/ *（必要）_ // _ fn main（）{let mut x = 10; y =＆mut x; println！（ "x = {}、y = {}"、x、_y）; * y = 11; println！（ "x = {}、y = {}"、x、* y）;} _ /
/ *しなければならなかった* / fn main（）{

let mut x = 10;
{
    let y = &x;

    println!("x={}, y={}", x, *y);
}

{
    let y = &mut x;

    *y = 11;
}

let y = &x;

println!("x={}, y={}", x, *y);

}

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/rust-lang/rust/issues/6393#issuecomment-89848449 。

https://github.com/rust-lang/rfcs/issues/811を支持して終了

@metajack元のコードのリンクは404です。このバグを読んでいる人のためにインラインで含めることはできますか？

少し掘り下げた後、これは元のコードと同等であると思います。
https://github.com/servo/servo/blob/5e406fab7ee60d9d8077d52d296f52500d72a2f6/src/servo/layout/box_builder.rs#L374

むしろ、それは私がこのバグを提出したときに使用した回避策です。 その変更前の元のコードは次のようです。
https://github.com/servo/servo/blob/7267f806a7817e48b0ac0c9c4aa23a8a0d288b03/src/servo/layout/box_builder.rs#L387 -L399

これらの特定の例はRust1.0より前のものであったため、現在どの程度関連しているかはわかりません。

@metajackこの問題の冒頭に、非常に単純な（1.0以降の）例があるとhttps://github.com/rust-lang/rfcs/issues/811の一部です

fn main() {
    let mut nums=vec![10i,11,12,13];
    *nums.get_mut(nums.len()-2)=2;
}

私が不満を言っていたのは次のようなものだったと思います。
https://is.gd/yfxUfw

その特定のケースは現在機能しているようです。

@vitiral私が当てはまると私が信じている今日のRustの例：

fn main() {
    let mut vec = vec!();

    match vec.first() {
        None => vec.push(5),
        Some(v) => unreachable!(),
    }
}

Noneアームはborrowckに失敗します。

不思議なことに、 Someアームでintをキャプチャしようとしない場合（つまり、 Some(_)使用する場合）、コンパイルされます。

@wyverlandああ、私は昨日それを打った、かなり迷惑です。

@metajack最初の投稿を編集して、その例を含めることができますか？

まだ毎晩ヒットしていませんが、これがコンパイルされたと言いたいだけです。

#![feature(nll)]

fn main() {
    let mut vec = vec!();

    match vec.first() {
        None => vec.push(5),
        Some(v) => unreachable!(),
    }
}