Rust: उधार लेने का दायरा हमेशा शाब्दिक नहीं होना चाहिए

तैयार उत्पादन के लिए नामांकन

मैं इसे या तो अच्छी तरह से परिभाषित या पिछड़ा-संगत कहूंगा।

जैको के उदाहरण

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

कोड को पुनर्गठित किया गया था, लेकिन यहाँ उधार चेकर का विशिष्ट तुष्टीकरण है जो मुझे करना था:

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

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

कुछ चर्चा के बाद, यह स्पष्ट है कि यहां वास्तविक समस्या यह है कि उधार चेकर उपनामों को ट्रैक करने के लिए कोई प्रयास नहीं करता है, बल्कि यह निर्धारित करने के लिए हमेशा क्षेत्र प्रणाली पर निर्भर करता है कि उधार कब दायरे से बाहर हो जाता है। मैं इसे बदलने के लिए अनिच्छुक हूं, कम से कम अल्पावधि में नहीं, क्योंकि कई अन्य बकाया मुद्दे हैं जिन्हें मैं पहले संबोधित करना चाहता हूं और कोई भी परिवर्तन उधार चेकर के लिए एक महत्वपूर्ण संशोधन होगा। एक अन्य संबंधित उदाहरण और कुछ विस्तृत विवरण के लिए अंक #6613 देखें।

मुझे आश्चर्य है कि क्या हम यह स्पष्ट करने के लिए त्रुटि संदेशों में सुधार कर सकते हैं कि क्या हो रहा है? लेक्सिकल स्कोप को समझना अपेक्षाकृत आसान है, लेकिन इस मुद्दे के उदाहरणों में जो मैंने इसे पार कर लिया है, किसी भी तरह से स्पष्ट नहीं था कि क्या हो रहा था।

बस एक बग, मील का पत्थर/नामांकन हटा रहा है।

दूर भविष्य के मील के पत्थर के लिए स्वीकार किया गया

ट्राइएज बंप

मेरे पास इसे ठीक करने के सर्वोत्तम तरीके के बारे में कुछ विचार हैं। मेरी मूल योजना यह है कि जब कोई मूल्य "बच निकलता है" की धारणा होगी। उस धारणा को औपचारिक रूप देने में कुछ काम लगेगा। मूल रूप से, जब एक उधार लिया गया सूचक बनाया जाता है, तो हम ट्रैक करेंगे कि यह बच गया है या नहीं। जब सूचक मर जाता

इन सबका सबसे दिलचस्प हिस्सा है भागने के नियम, बिल्कुल। मुझे लगता है कि नियमों को समारोह की औपचारिक परिभाषा को ध्यान में रखना होगा, और विशेष रूप से ज्ञान का लाभ उठाने के लिए हमें जीवन भर देना होगा। उदाहरण के लिए, सबसे भागने विश्लेषण करने पर विचार करेंगे एक सूचक p से बचने के लिए अगर वे की तरह एक फोन देखने foo(p) । लेकिन जरूरी नहीं कि हमें ऐसा करना ही पड़े। यदि समारोह के रूप में घोषित किया गया था:

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

तो वास्तव में हम जानते हैं कि foo पर करने के लिए नहीं रखता है p के लिए किसी भी अब जीवन भर की तुलना में a । हालांकि, 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 प्रकार के मापदंडों में प्रकट नहीं हो सकता है, और इसलिए हम जानते हैं कि यह कर सकता है' t उन में संग्रहीत किया जाता है, और यह किसी भी परिवर्तनशील स्थानों में प्रकट नहीं होता है। (ध्यान दें कि हम उसी निष्कर्ष एल्गोरिदम को लागू कर सकते हैं जैसा आज उपयोग किया जाता है और जिसका उपयोग # 3598 के लिए फिक्स के हिस्से के रूप में किया जाएगा ताकि हमें यह पता चल सके कि जीवनकाल एक परिवर्तनीय स्थान में दिखाई देता है या नहीं)

इसके बारे में सोचने का एक और तरीका यह नहीं है कि ऋण की समय सीमा समाप्त हो गई है, बल्कि यह है कि ऋण का दायरा शुरू होता है (आमतौर पर) उधार _variable_ से जुड़ा होता है और पूर्ण जीवनकाल नहीं होता है, और केवल पूर्ण जीवनकाल के लिए पदोन्नत किया जाता है जब चर _भागना_।

पुनर्उधार एक मामूली जटिलता है, लेकिन उन्हें विभिन्न तरीकों से नियंत्रित किया जा सकता है। रिबोरो तब होता है जब आप किसी उधार पॉइंटर की सामग्री को उधार लेते हैं - वे हर समय _होते हैं क्योंकि कंपाइलर उन्हें लगभग हर मेथड कॉल में स्वचालित रूप से सम्मिलित करता है। एक उधार सूचक let p = &v और let q = &*p जैसे पुनर्उधार पर विचार करें। यह अच्छा होगा यदि q मर गया था, तो आप p फिर से उपयोग कर सकते हैं - और यदि p और q दोनों मर गए थे, तो आप उपयोग कर सकते थे v फिर से (यह मानते हुए कि न तो p और न ही q बच निकलता है)। यहां जटिलता यह है कि यदि q बच जाता है, तो p को q के जीवनकाल के समाप्त होने तक एस्केप्ड अप माना जाना चाहिए। लेकिन मुझे लगता है कि यह स्वाभाविक रूप से _कुछ हद तक गिर जाता है कि हम इसे आज कैसे संभालते हैं: यानी, कंपाइलर नोट करता है कि q ने p उधार लिया है (शुरुआत में) आजीवन "q" (अर्थात, चर का ही) और यदि q बच जाना चाहिए, तो उसे पूर्ण शाब्दिक जीवनकाल में बढ़ावा दिया जाएगा। मुझे लगता है कि मुश्किल हिस्सा डेटाफ्लो में है, यह जानते हुए कि किल्स को कहां डालना है - हम p लिए किल को तुरंत सम्मिलित नहीं कर सकते हैं जब p मृत हो जाता है यदि इसे पुनर्उधार लिया जाता है। ओह ठीक है, मैं इस पर अधिक समय बर्बाद नहीं करूंगा, ऐसा लगता है कि यह करने योग्य है, और कम से कम सरल समाधान हैं जो सामान्य परिस्थितियों के लिए पर्याप्त होंगे (उदाहरण के लिए, p को पूरे जीवनकाल के लिए बचने के लिए विचार करें 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 उधार मृत हो जाता है, लेकिन निश्चित रूप से, उधार अभी पूरे मैच के लिए विस्तारित होता है।

मेरे पास इसे कोड करने के तरीके के बारे में और विचार हैं। मेरी मूल योजना यह है कि प्रत्येक ऋण के लिए दो बिट्स होंगे: एक बच निकला संस्करण और एक गैर-बचा हुआ संस्करण। प्रारंभ में हम गैर-बच निकला संस्करण जोड़ते हैं। जब कोई संदर्भ बच जाता है, तो हम बच गए बिट्स जोड़ते हैं। जब एक चर (या अस्थायी, आदि) मृत हो जाता है, तो हम गैर-एस्केप किए गए बिट्स को मार देते हैं - लेकिन बची हुई बिट्स (यदि सेट हो) को छूटे छोड़ दें। मेरा मानना ​​है कि इसमें सभी प्रमुख उदाहरण शामिल हैं।

सीसी @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. मैं input.fill_buf दो बार कॉल नहीं कर सकता, क्योंकि Buffer इंटरफ़ेस इस बात की गारंटी नहीं देता कि यह वह डेटा लौटाता है जिसे मैंने अभी-अभी दूसरी बार सत्यापित किया है। अगर मैं _do_ यह कोशिश करता हूं, तो कोड तकनीकी रूप से गलत है लेकिन टाइप चेकर इसे खुशी से पास करता है।
2. मैं top_up बारे में बहुत कुछ नहीं कर सकता, क्योंकि यह कोड का एक बुरा टुकड़ा है जिसे जटिल तरीकों से सबकुछ बदलने की जरूरत है।
3. मैं आपत्तिजनक बाइंड+टेस्ट+रिटर्न को किसी अन्य फ़ंक्शन में नहीं ले जा सकता, क्योंकि नए एपीआई में अभी भी सभी समान मुद्दे होंगे (जब तक कि if let मुझे _then_ बाइंड का परीक्षण करने की अनुमति नहीं देता है?)

यह लगभग ऐसा लगता है जैसे '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 लिए बाध्य था) के जीवनकाल को छोड़ रहा हूं, और तुरंत self आधार पर एक नया जीवनकाल लागू कर रहा हूं, जो self.input का मालिक है read का शाब्दिक जीवनकाल ब्लॉक ए के बराबर हो, और मैं नहीं चाहता कि इसे _lexical_ ब्लॉक स्तर तक फहराया जाए क्योंकि मैंने इसे return । स्पष्ट रूप से आजीवन चेकर को अभी भी यह साबित करने की आवश्यकता है कि परिणाम 'a के साथ जीवन भर संगत है, लेकिन मुझे समझ में नहीं आता कि इसका मतलब LIFETIME( read ) को LIFETIME( 'a साथ एकीकृत करने की आवश्यकता क्यों है)

यह पूरी तरह से संभव है कि मैं व्यापक रूप से भ्रमित हूं, या मेरा कोड बेहद असुरक्षित है। :-) लेकिन ऐसा लगता है कि यह काम करना चाहिए, अगर केवल इसलिए कि मैं बिना किसी समस्या के return self.input.fill_buf() कॉल कर सकता हूं। क्या उस अंतर्ज्ञान को औपचारिक रूप देने का कोई तरीका है?

@emk तो यह "हार्ड कोड" है कि SEME क्षेत्र (अर्थात, गैर-व्याख्यात्मक क्षेत्र) ठीक नहीं होते हैं, कम से कम अपने आप से नहीं। मेरे पास कंपाइलर में इसे अच्छी तरह से ठीक करने के बारे में कुछ विचार हैं, लेकिन यह SEME क्षेत्रों के लिए एक गैर-तुच्छ विस्तार है। आमतौर पर कोड का पुनर्गठन करके इसे हल करने का एक तरीका है। मुझे देखने दो कि क्या मैं इसके साथ खेल सकता हूं और एक अच्छा उदाहरण पेश कर सकता हूं।

मैं जानना चाहता हूं कि क्या 1.0 के लिए इस पर पुनर्विचार किया जा रहा है। यह हाल ही में एक _लॉट_ सामने आ रहा है, और मुझे डर है कि 1.0 के ध्यान में आने के बाद यह एक पेपरकट से मांस के घाव में बदल जाएगा। रस्ट की सबसे अधिक दिखाई देने वाली और चर्चित विशेषता के रूप में, उधार लेने के लिए पॉलिश और प्रयोग करने योग्य होना बहुत महत्वपूर्ण है।

क्या इसके लिए 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???
}

प्लेपेन

दोनों @pcwalton और @zwarich कुछ समय बिताया वास्तव में यह काम (एक संभव आरएफसी हाथ में हाथ आने के साथ) को लागू करने की कोशिश कर @bstrie। वे कुछ अप्रत्याशित जटिलता में भाग गए, जिसका अर्थ है कि यह आशा से कहीं अधिक काम करेगा। मुझे लगता है कि हर कोई आपसे सहमत है कि ये सीमाएं महत्वपूर्ण हैं और भाषा की पहली छाप को प्रभावित कर सकती हैं, लेकिन इसे पहले से निर्धारित पिछड़े-असंगत परिवर्तनों के विरुद्ध संतुलित करना कठिन है।

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

मुझे लगता है कि अगर यह 1.0 तक हल नहीं होता है, तो यह ऐसी चीज है जो लोगों को उधार जांच दृष्टिकोण को पूरी तरह से दोष देने के लिए प्रेरित करेगी, जब यह समस्या AFAIK उधार लेने के साथ स्वाभाविक रूप से असफल समस्या नहीं है।

@blaenk उधार चेकर को दोष नहीं देना मुश्किल है, मैंने दैनिक आधार पर इसमें और इसी तरह (जैसे @ गैंक्रो) में भाग लिया है। यह निराशाजनक है जब सामान्य समाधान gyrations है (उदाहरण के लिए एक काम के आसपास) / या आपके कोड को अधिक "अपरिवर्तनीय", कार्यात्मक, आदि के रूप में पुनर्गठित करने के लिए टिप्पणियां।

@mtanski हाँ, लेकिन गलती _does_ उधार चेकर AFAIK में है, इसे दोष देना गलत नहीं है। मैं जिस बात का जिक्र कर रहा हूं वह यह है कि यह नए लोगों को यह विश्वास करने के लिए प्रेरित कर सकता है कि यह उधार जांच _approach_ के साथ एक अंतर्निहित, मौलिक, असफल समस्या है, जो एक बहुत ही कपटी है, और AFAIK, गलत, विश्वास है।

मामले के लिए: "चलो 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);
}

प्रस्तावना में ड्रॉप () विधि है जो ऐसा करती है। लेकिन नहीं लगता
परिवर्तनीय उधार के साथ मदद करने के लिए।

सूर्य, अप्रैल 5, 2015 को 01:41 axeoth [email protected] लिखा है:

/* (वांछित) _/_fn मुख्य () { mut x = 10; चलो y = और म्यूट एक्स; println!("x={}, y={}", x, _y); *वाई = 11; println!("x={}, y={}", x, *y);}_/
/* को */fn मुख्य () { करना था

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

वह विशेष मामला अब काम करता प्रतीत होता है।

@vitral आज के जंग में एक उदाहरण जो मुझे लगता है कि लागू होता है:

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

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

None हाथ उधार लेने में विफल रहता है।

मजे की बात है, यदि आप int को Some बांह में पकड़ने की कोशिश नहीं करते हैं (यानी Some(_) ), तो यह संकलित हो जाता है।

@wyverland ओह हां, मैंने कल ही उसे मारा, बहुत कष्टप्रद।

@metajack क्या आप उस उदाहरण को शामिल करने के लिए पहली पोस्ट संपादित कर सकते हैं?

यह अभी तक रात में नहीं मारा गया है, लेकिन मैं सिर्फ इतना कहना चाहता हूं कि यह अब संकलित है:

#![feature(nll)]

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

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