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 에 바인딩되어 있기 때문에 'a Self 또는 K 유형 매개변수에 나타날 수 없기 때문에 가능하다는 것을 알고 있습니다. t 그것들에 저장되며, 변경 가능한 위치에는 나타나지 않습니다. (오늘 사용되는 것과 동일한 추론 알고리즘을 적용할 수 있으며 수명이 변경 가능한 위치에 나타나는지 여부를 알려주는 #3598 수정의 일부로 사용됩니다.)

이에 대해 생각하는 또 다른 방법은 대출이 _조기_ 만료된 것이 아니라 대출의 범위가 (일반적으로) 전체 수명이 아니라 빌린 _변수_와 연결되어 시작되고 변수가 다음과 같은 경우에만 전체 수명으로 승격된다는 것입니다. _탈출_.

재차입은 약간의 합병증이지만 다양한 방식으로 처리할 수 있습니다. 다시 빌리는 것은 빌린 포인터의 내용을 빌릴 때입니다. 컴파일러가 거의 모든 메서드 호출에 이를 자동으로 삽입하기 때문에 _항상_ 발생합니다. 빌린 포인터 let p = &v 와 let q = &*p 와 같은 재빌드를 고려하십시오. q 이 죽었을 때 p 다시 사용할 수 있으면 좋을 것입니다. 그리고 p 와 q 가 모두 죽었다면 다음을 사용할 수 있습니다. v 다시( p 또는 q 이스케이프가 없다고 가정). 여기에 합병증이있는 경우이다 q 탈출, p 의 수명까지 탈출을 고려해야합니다 q 만료됩니다. 그러나 나는 이것이 우리가 오늘 처리하는 방법을 자연스럽게 _somewhat_을 내리는 생각 : 즉, 컴파일러 노트가 q 빌린를 p 입니다 (처음에) 수명 "Q"(대한, 변수 자체의) 그리고 q 가 이스케이프되어야 하는 경우 전체 어휘 수명으로 승격됩니다. 나는 데이터 흐름에서 까다로운 부분이 킬을 삽입할 위치를 알고 있다고 생각합니다. 다시 빌릴 경우 p 가 죽으면 p 대한 킬을 즉시 삽입할 수 없습니다. 오 글쎄, 나는 이것에 더 많은 시간을 낭비하지 않을 것입니다. 그것은 가능한 것 같습니다. 그리고 최악의 경우 일반적인 상황에 적합한 더 간단한 솔루션이 있습니다(예: p 가 평생 동안 탈출했다고 생각하십시오. of q , q 대출 탈출 여부에 관계없이).

어쨌든 더 많은 생각이 필요하지만 이것이 어떻게 작동하는지 보기 시작했습니다. 나는 여전히 #2202와 #8624가 수정될 때까지 이와 같은 확장을 시작하는 것을 꺼려하는데, 이는 바로 차용의 두 가지 알려진 문제입니다. 또한 시스템을 확장하기 전에 건전성 증명에 대해 더 많은 진전을 이루고 싶습니다. 타임라인에 있는 다른 확장자는 #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 차입은 우리가 술어 평가를 마치자 마자 사라지지만 물론 지금은 차입이 전체 일치에 대해 확장된다는 추론입니다.

나는 이것을 어떻게 코딩할지에 대해 더 많은 생각을 했다. 내 기본 계획은 각 대출에 대해 이스케이프된 버전과 이스케이프되지 않은 버전의 두 가지 비트가 있다는 것입니다. 처음에는 이스케이프되지 않은 버전을 추가합니다. 참조가 이스케이프되면 이스케이프된 비트를 추가합니다. 변수(또는 임시 등)가 죽으면 이스케이프되지 않은 비트를 종료하지만 이스케이프된 비트(설정된 경우)는 그대로 둡니다. 나는 이것이 모든 주요 예를 포함한다고 믿습니다.

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
}

나를 참조

#9113의 좋은 예

나를 참조

내가 틀릴 수도 있지만 다음 코드도 이 버그를 치는 것 같습니다.

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. Buffer 인터페이스는 내가 두 번째로 유효성을 검사한 데이터를 반환한다고 보장하지 않기 때문에 input.fill_buf 두 번 호출할 수 없습니다. 내가 이것을 _do_ 하면 코드가 기술적으로 올바르지 않지만 유형 검사기는 이를 만족스럽게 전달합니다.
2. top_up 에 대해 많은 것을 할 수 없습니다. 복잡한 방식으로 모든 것을 변경해야 하는 사악한 코드이기 때문입니다.
3. 문제가 되는 bind+test+return을 다른 함수로 이동할 수 없습니다. 새 API에는 여전히 동일한 문제가 있기 때문입니다( if let _then_ bind?를 테스트할 수 있는 경우 제외).

'a 제약 조건이 이상적으로 read 다시 전파되어서는 안 되는 것처럼 느껴집니다. 하지만 난 여기 내 머리 위에 있어요. 다음에는 if let 를 시도하겠습니다.

글쎄요, if let 는 어젯밤 빌드에 포함되지 않았지만, 아마도 AST 재작성일 뿐이므로 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 에 바인딩됨)의 수명을 삭제하고 self.input 를 소유하는 self 기반으로 새 수명을 즉시 적용한다는 것입니다. self.input . 이상적으로는 read 가 블록 A 와 같은 어휘 수명을 갖기를 원하고 return 전달했기 때문에 _lexical_ 블록 수준까지 끌어올리는 것을 원하지 않습니다. 분명히 수명 검사기는 여전히 결과가 'a 와 호환되는 수명을 가지고 있음을 증명해야 하지만 이것이 LIFETIME( read )이 LIFETIME( 'a 과 통합되어야 함을 의미하는 이유를 이해하지 못합니다

내가 엄청나게 혼란스럽거나 내 코드가 끔찍하게 안전하지 않을 수 있습니다. :-) 하지만 아무 문제 없이 return self.input.fill_buf() 를 호출할 수만 있다면 이것이 작동해야 할 것 같습니다. 그 직관을 공식화하는 방법이 있습니까?

@emk 따라서 이것은 SEME 영역(즉, 어휘가 아닌 영역)이 적어도 자체적으로 수정되지 않는 "하드 코드"입니다. 컴파일러에서 잘 수정하는 방법에 대한 몇 가지 아이디어가 있지만 SEME 영역에 대한 사소한 확장입니다. 일반적으로 코드를 재구성하여 이 문제를 해결하는 방법이 있습니다. 내가 그것을 가지고 놀고 좋은 예를 만들 수 있는지 보자.

이것이 1.0에 대해 재검토되고 있는지 알고 싶습니다. 이것은 최근에 _많은_ 올라오고 있으며, 1.0이 관심을 모으게 되면 이것이 페이퍼컷에서 상처로 사라질까 두렵습니다. Rust의 가장 눈에 띄고 화제가 된 기능인 차용은 세련되고 사용 가능하도록 하는 것이 매우 중요합니다.

RFC에 이에 대한 기간이 있습니까?

@nikomatsakis 도움이된다면 Entry API에서 작동하지 않는 실제 간단한 예가 있습니다.

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에 _does_ 있습니다. 그것을 비난하는 것은 옳지 않습니다. 내가 말하는 것은 신규 이민자들이 그것이 차입 확인 _접근법_과 관련된 본질적이고 근본적이며 해결할 수 없는 문제라고 믿게 할 수 있고 AFAIK는 잘못된 믿음이라고 믿게 할 수 있다는 것입니다.

경우: "let p = &...; use-pa-bit-but-never-again; 예상 대출 만기일;" 현재로서는 해당 차용에 대한 범위 끝을 수동으로 선언하는 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일 일요일 오후 1시 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

이러한 특정 예가 녹슨 1.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 암이 차용에 실패했습니다.

흥미롭게도 Some 암에서 int 를 캡처하지 않으면(예: Some(_) ) 컴파일됩니다.

@wyverland 오 야, 어제 쳤는데 꽤

@metajack 해당 예제를 포함하도록 첫 번째 게시물을 편집할 수 있습니까?

아직 야간에 적중되지는 않았지만 이것이 이제 컴파일된다고 말하고 싶습니다.

#![feature(nll)]

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

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