1. इसके लिए एक फीचर गेट जोड़ें
2. switch और switchInt टर्मिनेटर में https://github.com/rust-lang/rust/blob/master/src/librustc_mir/transform/qualify_consts.rs#L347 में कस्टम कोड होना चाहिए यदि फीचर गेट सक्रिय है
3. एक एकल वर्तमान मूल ब्लॉक (https://github.com/rust-lang/rust/blob/master/src/librustc_mir/transform/qualify_consts.rs#L328) होने के बजाय इसे कुछ कंटेनर होने की आवश्यकता है जिसमें एक सूची है बुनियादी ब्लॉकों को अभी भी संसाधित करना है।

@ ओली-ओबीके यह थोड़ा पेचीदा है क्योंकि जटिल नियंत्रण-प्रवाह का मतलब है कि डेटाफ्लो विश्लेषण को नियोजित करने की आवश्यकता है। मुझे @alexreg पर वापस जाने और यह पता लगाने की आवश्यकता है कि उनके परिवर्तनों को कैसे एकीकृत किया जाए।

@eddyb शायद मेरी const-qualif शाखा (माइनस द टॉप कमिट) लेने के लिए एक अच्छा प्रारंभिक बिंदु होगा, इसे मास्टर पर रीबेस करें (मजेदार नहीं होने वाला), और फिर डेटा एनोटेशन सामान जोड़ें, है ना?

इस पर कोई भी समाचार?

@ मार्क-आईएम हां नहीं। मुझे लगता है कि @eddyb वास्तव में बहुत व्यस्त रहा है, क्योंकि मैं पिछले कुछ हफ्तों से उसे IRC पर पिंग करने में भी सक्षम नहीं हूं। अफसोस की बात है कि मेरी कॉन्स्ट-क्वालिफ शाखा भी संकलित नहीं होती है क्योंकि मैंने आखिरी बार इसे मास्टर पर रिबेट किया था। (मुझे विश्वास नहीं है कि मैंने अभी तक धक्का दिया है।)

thread 'main' panicked at 'assertion failed: position <= slice.len()', libserialize/leb128.rs:97:1
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: Could not compile `rustc_llvm`.

Caused by:
  process didn't exit successfully: `/Users/alex/Software/rust/build/bootstrap/debug/rustc --crate-name build_script_build librustc_llvm/build.rs --error-format json --crate-type bin --emit=dep-info,link -C opt-level=2 -C metadata=74f2a810ad96be1d -C extra-filename=-74f2a810ad96be1d --out-dir /Users/alex/Software/rust/build/x86_64-apple-darwin/stage1-rustc/release/build/rustc_llvm-74f2a810ad96be1d -L dependency=/Users/alex/Software/rust/build/x86_64-apple-darwin/stage1-rustc/release/deps --extern build_helper=/Users/alex/Software/rust/build/x86_64-apple-darwin/stage1-rustc/release/deps/libbuild_helper-89aaac40d3077cd7.rlib --extern cc=/Users/alex/Software/rust/build/x86_64-apple-darwin/stage1-rustc/release/deps/libcc-ead7d4af4a69e776.rlib` (exit code: 101)
warning: build failed, waiting for other jobs to finish...
error: build failed
command did not execute successfully: "/Users/alex/Software/rust/build/x86_64-apple-darwin/stage0/bin/cargo" "build" "--target" "x86_64-apple-darwin" "-j" "8" "--release" "--manifest-path" "/Users/alex/Software/rust/src/librustc_trans/Cargo.toml" "--features" " jemalloc" "--message-format" "json"
expected success, got: exit code: 101
thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1085:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
failed to run: /Users/alex/Software/rust/build/bootstrap/debug/bootstrap -i build

ठीक है, मजे की बात यह है कि मैंने आज ही फिर से रिबेस किया और ऐसा लगता है कि अब सब ठीक हो रहा है! ऐसा लगता है कि एक प्रतिगमन था, और यह अभी ठीक हो गया है। अब @eddyb पर।

@alexreg क्षमा करें, मैंने एक स्थानीय नींद कार्यक्रम में स्विच किया है और मैंने देखा है कि जब मैं जाग रहा हूं तो आपने मुझे पिंग किया है, लेकिन जब मैं जाग रहा हूं तो आप पूरे दिन ऑफ़लाइन हैं (
क्या मुझे आपकी शाखा से सिर्फ एक पीआर बनाना चाहिए? मैं भूल गया कि हमें इसके साथ क्या करना था?

@eddyb यह ठीक है हे। आपको जल्दी सो जाना चाहिए, क्योंकि मैं आमतौर पर 8:00 PM GMT से चालू रहता हूँ, लेकिन यह सब ठीक है! :-)

मुझे वास्तव में खेद है, मुझे यह महसूस करने में थोड़ा समय लगा कि प्रश्न में पैच की श्रृंखला को हटाने की आवश्यकता है Qualif::STATIC{,_REF} , यानी संकलन-समय पर सांख्यिकी तक पहुंचने में त्रुटियां। OTOH, यह पहले से ही const fn s और static s तक पहुंच के मामले में टूटा हुआ है:

#![feature(const_fn)]
const fn read<T: Copy>(x: &T) -> T { *x }
static FOO: u32 = read(&BAR);
static BAR: u32 = 5;
fn main() {
    println!("{}", FOO);
}

यह स्थिर रूप से नहीं पाया गया है, इसके बजाय miri शिकायत करता है कि "लटकने वाले सूचक को संदर्भित किया गया था" (जिसे वास्तव में "लटकने वाले सूचक" के बजाय static s के बारे में कुछ कहना चाहिए)।

तो मुझे लगता है कि संकलन-समय पर static s पढ़ना ठीक होना चाहिए, लेकिन कुछ लोग रनटाइम पर const fn "शुद्ध" (यानी "संदर्भित रूप से पारदर्शी" या उसके आस-पास) होना चाहते हैं, जिसका अर्थ यह होगा कि एक तर्क के रूप में प्राप्त संदर्भ के पीछे से const fn पढ़ना ठीक है, लेकिन const fn को कभी भी पतली हवा से बाहर static संदर्भ प्राप्त करने में सक्षम नहीं होना चाहिए (सहित const एस से)।

मुझे लगता है कि तब हम const s, const fn , और अन्य निरंतर संदर्भों (प्रमोशन सहित) में static s (भले ही उनका संदर्भ लेने के लिए ही) का उल्लेख करने से स्थिर रूप से इनकार कर सकते हैं।
लेकिन हमें अभी भी STATIC_REF हैक को हटाना होगा जो static s को अन्य static s का संदर्भ लेने की अनुमति देता है लेकिन (खराब कोशिश करता है और विफल रहता है) उन संदर्भों के पीछे से पढ़ने से इनकार करता है .

क्या हमें इसके लिए RFC की आवश्यकता है?

स्टैटिक्स से फेयर राइट रीडिंग लगता है। संदेह है कि इसे आरएफसी की जरूरत है, शायद सिर्फ एक क्रेटर रन, लेकिन फिर शायद मैं कहने के लिए सबसे अच्छा नहीं हूं।

ध्यान दें कि हम किसी भी चीज़ को प्रतिबंधित

ओह, मैंने गलत पढ़ा। तो कॉन्स मूल्यांकन अभी भी ध्वनि होगा, केवल संदर्भित रूप से पारदर्शी नहीं?

अंतिम पैराग्राफ एक संदर्भात्मक रूप से पारदर्शी दृष्टिकोण का वर्णन करता है (लेकिन हम उस संपत्ति को खो देते हैं यदि हम static s को const s और const fn s में उल्लेख करने की अनुमति देना शुरू करते हैं)। मुझे नहीं लगता कि सुदृढ़ता वास्तव में चर्चा में थी।

ठीक है, "लटकने वाला सूचक" निश्चित रूप से एक सुदृढ़ता के मुद्दे की तरह लगता है, लेकिन मैं इस पर आप पर भरोसा करूंगा!

"डैंगलिंग पॉइंटर" एक खराब त्रुटि संदेश है, यह सिर्फ मिरी को static s से पढ़ने से मना कर रहा है। केवल निरंतर संदर्भ जो static s को भी संदर्भित कर सकते हैं वे अन्य static s हैं, इसलिए हम उन पढ़ने को "बस" कर सकते हैं, क्योंकि वह सभी कोड हमेशा संकलन-समय पर एक बार चलते हैं।

(आईआरसी से) संक्षेप में, संदर्भित रूप से पारदर्शी const fn तर्कों के बिना केवल जमे हुए आवंटन तक पहुंच सकता है, जिसका अर्थ है कि const को समान प्रतिबंध की आवश्यकता है, और गैर-जमे हुए आवंटन केवल static से आ सकते हैं

मुझे रेफरेंशियल ट्रांसपेरेंसी को संरक्षित करना पसंद है इसलिए @eddyb का विचार शानदार लगता है!

हाँ, मैं कॉन्स fns को भी शुद्ध बना रहा हूँ।

कृपया ध्यान दें कि कुछ हानिरहित योजनाएं संदर्भात्मक पारदर्शिता को बर्बाद कर सकती हैं, जैसे:

let x = 0;
let non_deterministic = &x as *const _ as usize;
if non_deterministic.count_ones() % 2 == 0 {
    // do one thing
} else {
    // do a completely different thing
}

यह संकलन-समय पर एक मिरी त्रुटि के साथ विफल हो जाएगा, लेकिन रनटाइम पर गैर-नियतात्मक होगा (क्योंकि हम उस स्मृति पते को "सार" जैसे मिरी कैन के रूप में चिह्नित नहीं कर सकते हैं)।

संपादित करें: @Centril (इस तरह की तुलना और पूर्णांकों के लिए डाले के रूप में) कुछ कच्चे सूचक आपरेशन बनाने का विचार था unsafe भीतर const fn (जो हम कर सकते हैं जब तक हम स्थिर const fn ), और बताएं कि उनका उपयोग केवल उन तरीकों से किया जा सकता है जो मिरी संकलन-समय पर अनुमति देगा।
उदाहरण के लिए, एक ही स्थानीय में दो पॉइंटर्स घटाना ठीक होना चाहिए (आपको एक सापेक्ष दूरी मिलती है जो केवल प्रकार के लेआउट, सरणी इंडेक्स इत्यादि पर निर्भर करती है), लेकिन संदर्भ के पते को स्वरूपित करना ( {:p} ) गलत उपयोग है और इसलिए fmt::Pointer::fmt को const fn चिह्नित नहीं किया जा सकता है।
साथ ही कच्चे पॉइंटर्स के लिए Ord / Eq विशेषता संकेतों में से कोई भी const के रूप में चिह्नित नहीं किया जा सकता है (जब भी हमें उन्हें इस तरह से एनोटेट करने की क्षमता मिलती है), क्योंकि वे सुरक्षित हैं लेकिन ऑपरेशन unsafe में const fn ।

निर्भर करता है कि "हानिरहित" से आपका क्या मतलब है ... मैं निश्चित रूप से कारण देख सकता हूं कि हम ऐसे गैर-निर्धारक व्यवहार पर प्रतिबंध लगाना चाहते हैं।

इस पर काम जारी रहता तो बहुत अच्छा होता।

@lachlansneff यह आगे बढ़ रहा है ... जितनी जल्दी हम चाहेंगे, लेकिन काम किया जा रहा है। फिलहाल हम एक अवरोधक के रूप में https://github.com/rust-lang/rust/pull/51110 पर प्रतीक्षा कर रहे हैं।

@alexreg आह, धन्यवाद। एक मैच को चिह्नित करने में सक्षम होने के लिए यह बहुत उपयोगी होगा या यदि कॉन्स fn में नहीं होने पर भी कॉन्स के रूप में।

अब कोई स्थिति अपडेट है कि #51110 विलय हो गया है?

@programmerjake मैं विलय होने से पहले https://github.com/rust-lang/rust/pull/52518 पर @eddyb से कुछ प्रतिक्रिया की प्रतीक्षा कर रहा हूं (उम्मीद है कि बहुत जल्द)। वह हाल ही में बहुत व्यस्त रहा है (हमेशा उच्च मांग में), लेकिन वह पिछले कुछ दिनों में समीक्षाओं पर वापस आ गया है, इसलिए मैं आशान्वित हूं। उसके बाद, उसे व्यक्तिगत रूप से कुछ काम करने की आवश्यकता होगी, मुझे संदेह है, क्योंकि उचित डेटा प्रवाह विश्लेषण जोड़ना एक जटिल मामला है। हालांकि हम देखेंगे।

पहली पोस्ट में TODO सूचियों में कहीं, इसे वर्तमान भयानक हैक को हटाने के लिए जोड़ा जाना चाहिए जो && और || से & और | स्थिरांक के अंदर।

@ राल्फजंग पुराने कॉन्स eval का वह हिस्सा नहीं था, जो अब पूरा हो गया है कि MIRI CTFE जगह पर है?

AFAIK हम उस अनुवाद को HIR लोअरिंग में कहीं करते हैं, क्योंकि हमारे पास const_qualify में कोड है जो SwitchInt टर्मिनेटर को अस्वीकार करता है जो अन्यथा || / && द्वारा उत्पन्न किया जाएगा।

इसके अलावा, एक और बिंदु: @ ओली-ओबीके ने कहीं कहा (लेकिन मुझे कहां नहीं मिल रहा है) कि सशर्त किसी भी तरह से अधिक जटिल हैं जो भोलेपन से सोचेंगे ... क्या वह ड्रॉप/आंतरिक परिवर्तनशीलता के विश्लेषण के बारे में "बस" था?

क्या वह ड्रॉप/आंतरिक परिवर्तनशीलता के विश्लेषण के बारे में "बस" था?

मैं वर्तमान में इसे साफ़ करने की कोशिश कर रहा हूं। जब मेरे पास सारी जानकारी होगी तो आपसे संपर्क करूंगा

इसकी स्थिति क्या है? क्या इसके लिए जनशक्ति की आवश्यकता है या यह किसी समस्या के समाधान में अवरूद्ध है?

@ मार्क-आईएम यह कॉन्स्ट योग्यता के लिए उचित डेटाफ्लो विश्लेषण लागू करने पर अवरुद्ध है। @eddyb इस क्षेत्र में सबसे अधिक जानकार हैं, और उन्होंने पहले इस पर कुछ काम किया था। (तो मैं था, लेकिन उस तरह का स्थिर ...) अगर @eddyb के पास अभी भी समय नहीं है, तो शायद @ oli-obk या @RalfJung जल्द ही किसी बिंदु पर इससे निपट सकते हैं। :-)

58403 डेटा प्रवाह-आधारित योग्यता की दिशा में एक छोटा कदम है।

@eddyb आपने const fn में संदर्भात्मक पारदर्शिता को संरक्षित करने का उल्लेख किया है, जो मुझे लगता है कि एक अच्छा विचार है। क्या होगा यदि आपने const fn में पॉइंटर्स का उपयोग करने से रोका है? तो आपका पिछला कोड नमूना अब संकलित नहीं होगा:

let x = 0;
// compile time error: cannot cast reference to pointer in `const fun`
let non_deterministic = &x as *const _ as usize;
if non_deterministic.count_ones() % 2 == 0 {
    // do one thing
} else {
    // do a completely different thing
}

संदर्भों की अभी भी अनुमति होगी लेकिन आपको उनका आत्मनिरीक्षण करने की अनुमति नहीं दी जाएगी:

let x = 0;
let p = &x;
if *p != 0 {  // this is fine
    // do one thing
} else {
    // do a completely different thing
}

मुझे बताएं कि क्या मैं पूरी तरह से आधार से बाहर हूं, मैंने सोचा कि यह नियतात्मक बनाने का यह एक अच्छा तरीका होगा।

@ jyn514 जो पहले से ही अस्थिर (https://github.com/rust-lang/rust/issues/51910) के रूप में उपयोग करके कवर किया गया है, लेकिन उपयोगकर्ता कच्चे पॉइंटर्स की तुलना भी कर सकते हैं (https://github.com/rust- lang/rust/issues/53020) जो उतना ही खराब है और इस प्रकार अस्थिर भी है। हम इन्हें नियंत्रण प्रवाह से स्वतंत्र रूप से संभाल सकते हैं।

इस पर कोई नया?

https://rust-lang.zulipchat.com/#narrow/stream/146212 -t-compiler.2Fconst-eval/topic/dataflow-based.20const.20qualification.20MVP पर कुछ चर्चा है

@ ओली-ओबीके आपका लिंक काम नहीं करता है। यह क्या कहता है?

यह मेरे लिए काम करता है... हालांकि आपको Zulip में साइन इन करना होगा।

@alexreg हम्म हाँ, मुझे लगता है कि यह @alexreg क्या आप जानते हैं कि स्थिरांक में if और मिलान के लिए इसकी आवश्यकता क्यों है?

यदि हमारे पास डेटा प्रवाह आधारित संस्करण नहीं है तो हम या तो गलती से &Cell<T> को स्थिरांक के अंदर अनुमति दे देते हैं या गलती से None::<&Cell<T>> (जो स्थिर पर काम करता है। डेटा प्रवाह का खराब टूटा हुआ तदर्थ संस्करण हो)

@ est31 ठीक है, @ oli-obk इसे मुझसे बहुत बेहतर समझता है, लेकिन उच्च स्तर से मूल रूप से ब्रांचिंग से जुड़ी कोई भी चीज़ डेटाफ़्लो विश्लेषण की भविष्यवाणी करने वाली है जब तक कि आप किनारे के मामलों का एक गुच्छा नहीं चाहते। वैसे भी, ऐसा लगता है कि ज़ूलिप पर यह व्यक्ति इस पर काम करने की कोशिश कर रहा है, और यदि नहीं, तो मुझे पता है कि ओली-ओबीके और एडीब के इरादे हैं, शायद इस महीने या अगले (जब से मैंने उनसे इसके बारे में आखिरी बार बात की थी), हालांकि मैं कर सकता हूं उनकी ओर से वादे नहीं करेंगे/नहीं करेंगे।

@alexreg @mark-im @est31 @oli-obk मुझे इस सप्ताह कभी-कभी डेटाफ्लो-आधारित कॉन्स्ट योग्यता के अपने डब्ल्यूआईपी कार्यान्वयन को प्रकाशित करने में सक्षम होना चाहिए। यहां बहुत सारे संगतता खतरे हैं, इसलिए इसे वास्तव में मर्ज करने में कुछ समय लग सकता है।

बहुत अच्छा; इंतज़ार करूंगा।

(#57563 प्रति अनुरोध से कॉपी करना)

क्या विशेष मामले bool && bool , bool || bool , आदि के लिए संभव होगा? उन्हें वर्तमान में const fn में निष्पादित किया जा सकता है, लेकिन ऐसा करने के लिए बिटवाइज़ ऑपरेटरों की आवश्यकता होती है, जो कभी-कभी अवांछित होता है।

वे पहले से ही const और static वस्तुओं में विशेष-आवरण वाले हैं - उन्हें बिटवाइज़ संचालन में अनुवाद करके। लेकिन वह विशेष-आवरण एक बहुत बड़ा हैक है और यह सुनिश्चित करना बहुत कठिन है कि यह वास्तव में सही है। जैसा कि आपने कहा, यह कभी-कभी अवांछित भी होता है। इसलिए हम इसे अधिक बार नहीं करना चाहेंगे।

चीजों को सही करने में थोड़ा समय लगेगा, लेकिन ऐसा होगा। यदि हम इस बीच बहुत अधिक हैक करते हैं, तो हम खुद को एक ऐसे कोने में ले जा सकते हैं, जिससे हम बाहर नहीं निकल सकते (यदि उनमें से कुछ हैक गलत तरीके से बातचीत करते हैं, इस प्रकार गलती से व्यवहार को स्थिर कर देते हैं जो हम नहीं चाहते हैं)।

अब जबकि #64470 और #63812 को मिला दिया गया है, इसके लिए आवश्यक सभी उपकरण कम्पाइलर में मौजूद हैं। मुझे यह सुनिश्चित करने के लिए कि यह सुविधा सक्षम होने के साथ अनावश्यक रूप से अक्षम नहीं है, मुझे अभी भी कॉन्स्ट योग्यता के आसपास क्वेरी सिस्टम में कुछ बदलाव करने की आवश्यकता है। हम यहां प्रगति कर रहे हैं, और मेरा मानना ​​है कि इसका एक प्रयोगात्मक कार्यान्वयन रात में हफ्तों में उपलब्ध होगा, महीनों में नहीं (प्रसिद्ध अंतिम शब्द: मुस्कान :)।

@ परमानंद-मोर्स सुनकर बहुत अच्छा लगा! इसे पूरा करने के लिए आपके ठोस प्रयासों के लिए धन्यवाद; मैं व्यक्तिगत रूप से पिछले कुछ समय से इस सुविधा के लिए उत्सुक हूं।

यह हो जाने के बाद सीटीएफई के लिए ढेर आवंटन समर्थन देखना अच्छा लगेगा। मुझे नहीं पता कि आप या किसी और की इस पर काम करने में दिलचस्पी है या नहीं, लेकिन अगर नहीं तो शायद मैं मदद कर सकूं।

@alexreg धन्यवाद!

संकलन समय पर ढेर आवंटन के बारे में चर्चा rust-rfcs/const-eval#20 पर समाप्त हो गई है। AFAIK, सबसे हाल के घटनाक्रमों के चारों ओर एक थे ConstSafe / ConstRefSafe प्रतिमान निर्धारण सीधे देखा जा सकता है / एक के अंतिम मूल्य में एक संदर्भ के पीछे के लिए const । मुझे लगता है कि हालांकि और अधिक डिज़ाइन कार्य की आवश्यकता है।

साथ चलने वालों के लिए, #65949 (जो स्वयं कुछ छोटे पीआर पर निर्भर करता है) इसके लिए अगला अवरोधक है। हालांकि यह केवल मूर्त रूप से संबंधित प्रतीत हो सकता है, तथ्य यह है कि कॉन्स्ट-चेकिंग/योग्यता इतनी कसकर पदोन्नति के साथ मिलकर इस सुविधा को इतने लंबे समय तक अवरुद्ध करने का कारण था। मैं एक बाद के पीआर खोलने की योजना बना रहा हूं जो पुराने कॉन्स्ट-चेकर को पूरी तरह से हटा देगा (वर्तमान में हम समानांतर में दोनों चेकर्स चलाते हैं)। यह उन अक्षमताओं से बच जाएगा जिनका मैंने पहले उल्लेख किया था।

उपरोक्त दोनों पीआर के विलय के बाद, स्थिरांक में if और match कुछ निदान सुधार होंगे और एक फीचर फ्लैग दूर होगा! ओह, और परीक्षण भी, इतने सारे परीक्षण ...

यदि आपको परीक्षणों की आवश्यकता है, तो मुझे नहीं पता कि कैसे शुरू किया जाए, लेकिन मैं योगदान देने के लिए तैयार हूं! बस मुझे बताएं कि परीक्षण कहां जाना चाहिए/उन्हें कैसा दिखना चाहिए/मुझे किस शाखा का आधार कोड बंद करना चाहिए :)

देखने के लिए अगला पीआर #66385 है। यह नए डेटाफ्लो-आधारित संस्करण के पक्ष में पुराने कॉन्स्ट योग्यता तर्क (जो ब्रांचिंग को संभाल नहीं सका) को पूरी तरह से हटा देता है।

@ jyn514 यह बहुत अच्छा होगा! जब मैं कार्यान्वयन का मसौदा तैयार करना शुरू करूंगा तो मैं आपको पिंग करूंगा। एक बार रात में if और match उपलब्ध हो जाने पर लोगों के लिए कॉन्स्ट सुरक्षा (विशेषकर HasMutInterior भाग) का उल्लंघन करने का प्रयास करना भी बहुत मददगार होगा।

66507 में RFC 2342 का प्रारंभिक कार्यान्वयन शामिल है।

मुझे उम्मीद है कि खुरदुरे किनारों को हटाने में कुछ समय लगेगा, विशेष रूप से निदान के संबंध में, और परीक्षण कवरेज बहुत विरल है ( @ jyn514 हमें उस मुद्दे पर समन्वय करना चाहिए)। फिर भी, मुझे उम्मीद है कि हम इसे अगले कुछ हफ़्तों में फ़ीचर फ़्लैग के पीछे रिलीज़ कर सकते हैं।

इसे #66507 में लागू किया गया था और अब इसे नवीनतम रात्रिकालीन में उपयोग किया जा सकता है। एक अंदरूनी जंग ब्लॉग पोस्ट भी है जो नए उपलब्ध संचालन के साथ-साथ कुछ मुद्दों का विवरण देता है जो आपको मौजूदा कार्यान्वयन के साथ आंतरिक परिवर्तनशीलता या एक कस्टम Drop impl के साथ सामना कर सकते हैं।

आगे बढ़ो और दृढ़ करो!

ऐसा लगता है कि समानता const ? या मैं गलत हूँ:

error[E0019]: constant function contains unimplemented expression type
  --> src/liballoc/raw_vec.rs:55:22
   |
55 |         let cap = if mem::size_of::<T>() == 0 { !0 } else { 0 };
   |                      ^^^^^^^^^^^^^^^^^^^^^^^^

error[E0019]: constant function contains unimplemented expression type
  --> src/liballoc/raw_vec.rs:55:19
   |
55 |         let cap = if mem::size_of::<T>() == 0 { !0 } else { 0 };
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 2 previous errors

@ मार्क-आईएम यह वास्तव में काम करना चाहिए। शायद बूटस्ट्रैपिंग समस्या? आइए जूलिप पर चर्चा करते हैं।

सुनिश्चित नहीं है कि यह जानबूझकर है, लेकिन एक एनम पर मिलान करने का प्रयास त्रुटि देता है

अगम्य कोड के साथ const fn स्थिर नहीं है

इस तथ्य के बावजूद कि एनम संपूर्ण है और एक ही टोकरे में परिभाषित है।

@jhpratt क्या आप कोड पोस्ट कर सकते हैं? मैं बिना किसी समस्या के साधारण एनम्स पर मैच कर सकता हूं: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=585e9c2823afcb49c6682f69569c97ea

@jhpratt क्या आप कोड पोस्ट कर सकते हैं? मैं बिना किसी समस्या के साधारण एनम पर मेल कर सकता हूं:

यहां:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13a9fbc4251d7db80f5d63b1dc35a98b

मुझे दो सेकंड के लिए मारो। यह मेरा सटीक मामला प्रदर्शित करने वाला एक न्यूनतम उदाहरण है।

@jhpratt निश्चित रूप से जानबूझकर नहीं। क्या आप कोई मुद्दा खोल सकते हैं?

कृपया विशिष्ट कार्यों या मुद्दों के पुनर्निर्देशन को पुनर्निर्देशित करें जिन्हें आप ताजा मुद्दों पर रिपोर्ट करना चाहते हैं और उन्हें उचित रूप से F-const_if_match साथ लेबल करें ताकि यह मुद्दे महत्वपूर्ण घटनाओं को अस्पष्ट करने वाली अल्पकालिक टिप्पणियों से भर न जाए।

@Centril शीर्ष टिप्पणी में डालने के लिए कोई बुरी बात नहीं है ताकि आपका दफन न हो।

स्थिति अपडेट:

यह कार्यान्वयन के नजरिए से स्थिरीकरण के लिए तैयार है, लेकिन सवाल यह है कि क्या हम मूल्य आधारित डेटाफ्लो रखना चाहते हैं जो अभी हमारे पास एक प्रकार आधारित (लेकिन कम शक्तिशाली) के बजाय है। मूल्य आधारित डेटा प्रवाह थोड़ा अधिक महंगा है (उस पर और अधिक नीचे), और हमें इसकी आवश्यकता कार्यों के लिए है

const fn foo<T>() {
    let x = Option::<T>::None;
    {x};
}

जिसे एक प्रकार आधारित विश्लेषण अस्वीकार कर देगा, क्योंकि Option<T> में विध्वंसक हो सकते हैं जो अब चलाने का प्रयास करेंगे और इस प्रकार गैर-कॉन्स्ट कोड निष्पादित कर सकते हैं।

जब शाखाएं होती हैं तो हम एक प्रकार आधारित विश्लेषण पर वापस आ सकते हैं, लेकिन इसका मतलब यह होगा कि हम अस्वीकार कर देंगे

const fn foo<T>(b: bool) {
    let x = Option::<T>::None;
    assert!(b);
    {x};
}

जो शायद यूजर्स के लिए काफी हैरान करने वाला होगा।

@ ecstatic-morse ने सभी कार्यों पर विश्लेषण चलाया, न कि केवल const fn और 5% तक की मंदी देखी (https://perf.rust-lang.org/compare.html?start=93dc97a85381cc52eb872d27e50e4d518926a27c&end=51cf313c7946365d5be3811395702c6a)। ध्यान दें कि यह एक निराशावादी संस्करण है, क्योंकि इसका मतलब है कि यह उन कार्यों पर भी चलाया जाता है जो const fn नहीं बन सकते हैं और अक्सर नहीं बन सकते हैं।

इसका मतलब यह है कि अगर हम बहुत सारे फंक्शन कॉन्स्ट एफएन बनाते हैं, तो हम इस मूल्य आधारित विश्लेषण के कारण कुछ संकलन मंदी देख सकते हैं।

एक मध्यम आधार केवल मूल्य आधारित विश्लेषण चलाने के लिए हो सकता है यदि प्रकार आधारित विश्लेषण विफल हो जाता है। इसका मतलब यह है कि यदि कोई विनाशक नहीं हैं, तो हमें यह पता लगाने के लिए मूल्य आधारित विश्लेषण चलाने की आवश्यकता नहीं है कि क्या अस्तित्वहीन विनाशक नहीं चलेंगे (हाँ मुझे पता है, यहां बहुत सारी नकारात्मकताएं हैं)। इसे अलग तरह से वाक्यांशित करने के लिए: हम केवल मूल्य आधारित विश्लेषण चलाते हैं यदि विनाशक मौजूद हैं।

मैं इसे @rust-lang/lang चर्चा के लिए नामांकित कर रहा हूं ताकि हम यह पता लगा सकें कि क्या हम साथ जाना चाहते हैं

• लूप या शाखाओं की उपस्थिति में प्रकार आधारित विकल्प (उपयोगकर्ताओं को अजीब व्यवहार देना)
• पूर्ण मूल्य आधारित विश्लेषण (अधिक महंगा, लेकिन उपयोगकर्ताओं के लिए पूर्ण अभिव्यक्ति)
• मिश्रित योजना, उपयोगकर्ताओं के लिए अभी भी पूर्ण अभिव्यक्ति, कुछ अतिरिक्त जटिलता, लेकिन उन मामलों में संकलन-समय की समस्याओं को कम करना चाहिए जिन्हें इसकी आवश्यकता है।

@ ओली-ओबीके

लूप या शाखाओं की उपस्थिति में प्रकार आधारित विकल्प (उपयोगकर्ताओं को अजीब व्यवहार देना)

बस इस पर जाँच करने के लिए: क्या यह स्ट्रेटलाइन कोड में भी टाइप-आधारित विश्लेषण करने का विकल्प नहीं है? मुझे लगता है कि यह पिछड़ा असंगत है, यह देखते हुए कि हम पहले से ही निम्नलिखित ( खेल का मैदान ) स्वीकार करते हैं:

struct Foo { }

impl Drop for Foo {
    fn drop(&mut self) { }
}

const T: Option<Foo> = None;

fn main() { }

व्यक्तिगत रूप से, मुझे लगता है कि हमें उपयोगकर्ताओं के लिए अधिक सुसंगत, बेहतर अनुभव पर जोर देना चाहिए। ऐसा लगता है कि हम आवश्यकतानुसार अनुकूलित कर सकते हैं, और किसी भी मामले में लागत बहुत खराब नहीं है। लेकिन मैं थोड़ा बेहतर ढंग से समझना चाहता हूं कि इस अधिक महंगे विश्लेषण में क्या हो रहा है: यह विचार है कि हम मूल रूप से "निरंतर प्रचार" कर रहे हैं, जैसे कि जब भी कुछ गिरा दिया जाता है, तो हम यह निर्धारित करने के लिए सटीक मूल्य का विश्लेषण करते हैं कि क्या इसमें एक मूल्य हो सकता है जिसे विनाशक चलाने की आवश्यकता होगी? (यानी, यदि यह None , तो Option<T> के सामान्य उदाहरण का उपयोग करने के लिए)

बस इस पर जाँच करने के लिए: क्या यह स्ट्रेटलाइन कोड में भी टाइप-आधारित विश्लेषण करने का विकल्प नहीं है? मुझे लगता है कि यह पिछड़ा असंगत है, यह देखते हुए कि हम पहले से ही निम्नलिखित (खेल का मैदान) स्वीकार करते हैं:

हां, यही कारण है कि हम पूरी तरह से टाइप आधारित विश्लेषण की ओर नहीं बढ़ सकते।

क्या यह विचार है कि हम मूल रूप से "निरंतर प्रचार" कर रहे हैं, जैसे कि जब भी कुछ गिरा दिया जाता है, तो हम यह निर्धारित करने के लिए गिराए जा रहे सटीक मूल्य का विश्लेषण करते हैं कि क्या इसमें एक मूल्य हो सकता है जिसे विनाशक चलाने की आवश्यकता होगी? (अर्थात, यदि यह कोई नहीं है, तो Option . के सामान्य उदाहरण का उपयोग करने के लिए)

हम केवल झंडे की एक सूची का प्रचार कर रहे हैं ( Drop और Freeze , मैंने अभी यहां Drop दिखाया है क्योंकि इसे समझाना आसान है)। जब हम Drop टर्मिनेटर तक बिना Drop ध्वज सेट किए पहुँच जाते हैं, तो हम Drop टर्मिनेटर को नज़रअंदाज़ कर देते हैं। यह निम्नलिखित की तरह कोड की अनुमति देता है:

{
    let mut x = None;
    // Drop flag for x: false
    let y = Some(Foo);
    // Drop flag for y: true
    x = y; // Dropping x is fine, because Drop flag for x is false
    // Drop flag for y: false, Drop flag for x: true
    x
    // Dropping y is fine, because Drop flag for y is false
}

यह मूल्यांकन के समय नहीं होता है, इसलिए निम्नलिखित ठीक नहीं है:

{
    let mut x = Some(Foo);
    if false {
        x = None;
    }
    x
}

हम जांचते हैं कि सभी संभावित निष्पादन पथ Drop कारण नहीं बनते हैं।

हालांकि लगातार प्रचार एक अच्छा सादृश्य है। यह एक और डेटाफ्लो समस्या है जिसका स्थानांतरण फ़ंक्शन जीन/किल सेट के साथ व्यक्त नहीं किया जा सकता है, जो चर के बीच प्रतिलिपि स्थिति को संभाल नहीं पाता है। हालाँकि, निरंतर प्रसार को प्रत्येक चर के वास्तविक मूल्य को संग्रहीत करने की आवश्यकता होती है, लेकिन कॉन्स्ट-चेकिंग को केवल एक बिट को संग्रहीत करने की आवश्यकता होती है जो यह दर्शाता है कि क्या उस चर का एक कस्टम Drop impl है या Freeze इसे नहीं बना रहा है निरंतर प्रसार की तुलना में थोड़ा कम खर्चीला होगा।

स्पष्ट होने के लिए, @ oli-obk का पहला उदाहरण आज स्थिर पर संकलित है, और 1.38.0 के बाद से है, जिसमें #64470 शामिल नहीं है।

इसके अलावा, const X: Option<Foo> = None; 1.0 के बाद से संकलित है, बाकी सब कुछ उस से सिर्फ एक प्राकृतिक विस्तार है जो नई सुविधाओं के साथ है जो कि const eval ने प्राप्त किया है।

ठीक है, मेरा मानना ​​है कि तब विशुद्ध रूप से मूल्य-आधारित विकल्प को अपनाना समझ में आता है।

मुझे लगता है कि हम इसे बैठक में शामिल कर सकते हैं और वापस रिपोर्ट कर सकते हैं =)

सारांश

मेरा प्रस्ताव है कि हम वर्तमान शब्दार्थ के साथ #![feature(const_if_match)] को स्थिर करें।

विशेष रूप से, if और match अभिव्यक्तियों के साथ-साथ शॉर्ट-सर्किटिंग लॉजिक ऑपरेटर && और || सभी कॉन्स्टेबल संदर्भों में कानूनी हो जाएंगे। एक कॉन्स संदर्भ निम्न में से कोई भी है:

• const , static , static mut या एनम विवेचक का प्रारंभकर्ता।
• एक const fn का शरीर।
• एक कास्ट जेनेरिक का मान (केवल रात में)।
• एक सरणी प्रकार की लंबाई ( [u8; 3] ) या एक सरणी दोहराव अभिव्यक्ति ( [0u8; 3] )।

इसके अलावा, शॉर्ट-सर्किटिंग लॉजिक ऑपरेटरों को अब const और static इनिशियलाइज़र्स में उनके बिटवाइज़ समकक्ष ( & और | क्रमशः) तक कम नहीं किया जाएगा (देखें #57175)। परिणामस्वरूप, let बाइंडिंग का उपयोग उन इनिशियलाइज़र्स में शॉर्ट-सर्किटिंग लॉजिक के साथ किया जा सकता है।

ट्रैकिंग समस्या: #49146
संस्करण लक्ष्य: 1.45 (2020-06-16)

कार्यान्वयन इतिहास

64470 ने एक मूल्य-आधारित स्थिर विश्लेषण लागू किया जो सशर्त नियंत्रण-प्रवाह का समर्थन करता था और डेटा प्रवाह पर आधारित था। इसने, #63812 के साथ, हमें पुराने कॉन्स्ट-चेकिंग कोड को जटिल नियंत्रण-प्रवाह ग्राफ़ पर काम करने वाले कोड से बदलने की अनुमति दी। पुराने कॉन्स्ट-चेकर को एक समय के लिए डेटाफ्लो-आधारित के साथ समानांतर में चलाया गया था ताकि यह सुनिश्चित हो सके कि वे सरल नियंत्रण प्रवाह वाले कार्यक्रमों पर सहमत हैं। #66385 ने डेटा प्रवाह-आधारित के पक्ष में पुराने कॉन्स्ट-चेकर को हटा दिया।

66507 ने #![feature(const_if_match)] फीचर गेट को सिमेंटिक के साथ लागू किया जिसे अब स्थिरीकरण के लिए प्रस्तावित किया जा रहा है।

कॉन्स्ट योग्यता

पृष्ठभूमि

[मिरी] ने कई वर्षों से rustc कंपाइल-टाइम फंक्शन मूल्यांकन (CTFE) संचालित किया है, और कम से कम इतने लंबे समय के लिए सशर्त बयानों का मूल्यांकन करने में सक्षम है। CTFE के दौरान, हमें कुछ कार्यों से बचना चाहिए, जैसे कि कस्टम Drop impls को कॉल करना या आंतरिक परिवर्तनशीलता वाले मान का संदर्भ लेना। सामूहिक रूप से, इन अयोग्य गुणों को "योग्यता" के रूप में जाना जाता है, और यह निर्धारित करने की प्रक्रिया कि कार्यक्रम में एक विशिष्ट बिंदु पर एक मूल्य की योग्यता है या नहीं, "कॉन्स्ट योग्यता" के रूप में जाना जाता है।

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

हमारे स्थिर विश्लेषण को एक प्रकार के संदर्भ को आंतरिक परिवर्तनशीलता (जैसे &Cell<i32> ) के साथ const के अंतिम मान में प्रदर्शित होने से रोकना चाहिए। यदि इसकी अनुमति दी जाती है, तो रन-टाइम पर const को संशोधित किया जा सकता है।

const X: &std::cell::Cell<i32> = std::cell::Cell::new(0);

fn main() {
  X.get(); // 0
  X.set(42);
  X.get(); // 42
}

हालांकि, हम उपयोगकर्ता को एक const परिभाषित करने की अनुमति देते हैं जिसके प्रकार में आंतरिक परिवर्तनशीलता ( !Freeze ) है, जब तक हम यह साबित कर सकते हैं कि उस const का अंतिम मूल्य नहीं है। उदाहरण के लिए, निम्नलिखित स्थिर जंग के पहले संस्करण के बाद से संकलित किया

const _X: Option<&'static std::cell::Cell<i32>> = None;

स्थिर विश्लेषण के लिए यह दृष्टिकोण, जिसे मैं टाइप-आधारित के विपरीत मूल्य-आधारित कहूंगा, का उपयोग उस कोड की जांच के लिए भी किया जाता है जिसके परिणामस्वरूप कस्टम Drop impl कहा जा सकता है। Drop impls को कॉल करना समस्याग्रस्त है क्योंकि उन्हें कॉन्स्ट-चेक नहीं किया जाता है और इस प्रकार कोड हो सकता है जिसे कॉन्स्ट संदर्भ में अनुमति नहीं दी जाएगी। मूल्य-आधारित तर्क को let कथनों का समर्थन करने के लिए विस्तारित किया गया था, जिसका अर्थ है कि जंग 1.42.0 स्थिर पर निम्नलिखित

const _: Option<Vec<i32>> = {
  let x = None;
  let mut y = x;
  y = Some(Vec::new()); // Causes the old value in `y` to be dropped.
  y
};

वर्तमान रात्रिकालीन शब्दार्थ

#![feature(const_if_match)] का वर्तमान व्यवहार डेटाफ्लो का उपयोग करके जटिल नियंत्रण-प्रवाह ग्राफ़ पर काम करने के लिए मूल्य-आधारित शब्दार्थ का विस्तार करता है। दूसरे शब्दों में, हम यह साबित करने का प्रयास करते हैं कि कार्यक्रम के माध्यम से सभी संभावित पथों के साथ एक चर के पास प्रश्न में योग्यता नहीं है।

enum Int {
    Zero,
    One,
    Many(String), // Dropping this variant is not allowed in a `const fn`...
}

// ...but the following code is legal under this proposal...
const fn good(x: i32) {
    let i = match x {
        0 => Int::Zero,
        1 => Int::One,
        _ => return,
    };

    // ...because `i` is never `Int::Many` on any possible path through the program.
    std::mem::drop(i);
}

कार्यक्रम के माध्यम से सभी संभावित पथों में वे शामिल हैं जो अभ्यास में कभी नहीं पहुंच सकते हैं। एक उदाहरण, ऊपर के समान Int एनम का उपयोग करना:

const fn bad(b: bool) {
    let i = if b == true {
        Int::One
    } else if b == false {
        Int::Zero
    } else {
        // This branch is dead code. It can never be reached in practice.
        // However, const qualification treats it as a possible path because it
        // exists in the source.
        Int::Many(String::new())
    };

    // ILLEGAL: `i` was assigned the `Int::Many` variant on at least one code path.
    std::mem::drop(i);
}

यह विश्लेषण फ़ंक्शन कॉल को अपारदर्शी मानता है, यह मानते हुए कि उनके रिटर्न वैल्यू में इसके प्रकार का कोई भी मूल्य हो सकता है। जैसे ही एक परिवर्तनीय संदर्भ बनाया जाता है, वैसे ही हम एक चर के लिए एक प्रकार-आधारित विश्लेषण पर वापस आते हैं। ध्यान दें कि स्थिर जंग पर वर्तमान में एक स्थिरांक संदर्भ में एक परिवर्तनीय संदर्भ बनाना प्रतिबंधित है।

#![feature(const_mut_refs)]

const fn none() -> Option<Cell<i32>> {
    None
}

// ILLEGAL: We must assume that `none` may return any value of type `Option<Cell<i32>>`.
const BAD: &Option<Cell<i32>> = none();

const fn also_bad() {
    let x = Option::<Box<i32>>::None;

    let _ = &mut x;

    // ILLEGAL: because a mutable reference to `x` was created, we can no
    // longer assume anything about its value.
    std::mem::drop(x)
}

आप अधिक उदाहरण देख सकते हैं कि कैसे एक मूल्य-आधारित विश्लेषण आंतरिक परिवर्तनशीलता और कस्टम ड्रॉप इम्प्लांट्स के आसपास रूढ़िवादी है, साथ ही कुछ मामलों में जहां एक रूढ़िवादी विश्लेषण यह साबित करने में सक्षम है कि परीक्षण सूट में कुछ भी अवैध नहीं हो सकता है।

वैकल्पिक

मुझे मौजूदा दृष्टिकोण के व्यावहारिक, पश्चगामी संगत विकल्पों के साथ आने में मुश्किल हुई है। जैसे ही एक कॉन्स्टेबल संदर्भ में सशर्त उपयोग किया जाता है, हम सभी चर के लिए टाइप-आधारित विश्लेषण पर वापस आ सकते हैं। हालांकि, उपयोगकर्ताओं को यह समझाना भी मुश्किल होगा, क्योंकि प्रतीत होता है कि असंबंधित परिवर्धन कोड को अब संकलित नहीं करेगा, जैसे कि assert निम्नलिखित उदाहरण में @oli-obk से।

const fn foo<T>(b: bool) {
    let x = Option::<T>::None;
    assert!(b);
    {x};
}

मूल्य-आधारित विश्लेषण की बढ़ी हुई अभिव्यक्ति मुक्त नहीं है। एक पूर्ण रन जिसने सभी आइटम निकायों पर केवल const वाले नहीं, पर योग्यता की, चेक बिल्ड पर 5% प्रतिगमन दिखाया। यह सबसे खराब स्थिति है, क्योंकि यह मानता है कि भविष्य में किसी बिंदु पर सभी वस्तुओं को const बनाया जाएगा। संभावित अनुकूलन, जैसे कि #71330 में से एक, पर पहले थ्रेड में चर्चा की गई है।

भविष्य का कार्य

फिलहाल, ड्रॉप विस्तार से पहले कॉन्स्ट-चेकिंग चलाया जाता है, जिसका अर्थ है कि कुछ ड्रॉप टर्मिनेटर एमआईआर में रहते हैं जो अभ्यास में पहुंच योग्य नहीं हैं। यह Option::unwrap को const fn बनने से रोक रहा है (#66753 देखें)। इसे हल करना बहुत कठिन नहीं है, लेकिन इसके लिए कॉन्स्ट-चेकिंग पास को दो चरणों (प्री- और पोस्ट-ड्रॉप विस्तार) में विभाजित करने की आवश्यकता होगी।

एक बार #![feature(const_if_match)] स्थिर हो जाने पर, पुस्तकालय कार्यों का एक बड़ा सौदा const fn बनाया जा सकता है। इसमें आदिम पूर्णांक प्रकारों पर कई विधियाँ शामिल हैं, जिनकी गणना #53718 में की गई है।

एक कॉन्स संदर्भ में लूप सशर्त के समान कॉन्स्ट योग्यता प्रश्न पर अवरुद्ध हैं। वर्तमान डेटा प्रवाह-आधारित दृष्टिकोण बिना किसी संशोधन के चक्रीय CFG के लिए भी काम करता है, इसलिए यदि #![feature(const_if_match)] को स्थिर किया जाता है, तो #52000 के लिए मुख्य अवरोधक समाप्त हो जाएगा।

स्वीकृतियाँ

विशेष धन्यवाद @ oli-obk और @eddyb के कारण हैं , जो अधिकांश कार्यान्वयन कार्यों के लिए प्राथमिक समीक्षक थे, साथ ही बाकी @rust-lang/wg-const-eval ने मुझे कॉन्स्ट के आसपास के प्रासंगिक मुद्दों को समझने में मदद की। योग्यता। इनमें से कोई भी मिरी के बिना संभव नहीं होगा, जिसे @solson द्वारा बनाया गया था और अब @RalfJung और @ oli-obk द्वारा बनाए रखा गया है।

यह FCP से पहले की स्थिरीकरण रिपोर्ट होने का इरादा है। मैं नहीं खोल सकता FCP, तथापि.

@ परमानंद-मोर्स इस मुद्दे पर आपकी कड़ी मेहनत के लिए बहुत-बहुत धन्यवाद!

बढ़िया रिपोर्ट!

एक चीज जो मुझे लगता है कि मैं देखना चाहूंगा, @ परमानंद-मोर्स, है

• रेपो में कुछ प्रतिनिधि परीक्षणों के लिंक, ताकि हम व्यवहार का निरीक्षण कर सकें
• क्या सेवर या कुछ और के आसपास निहितार्थ हैं - मुझे लगता है कि उत्तर काफी हद तक नहीं है , है ना? दूसरे शब्दों में, हम यह निर्धारित करने के लिए उपयोग किए गए विश्लेषण पर निर्णय ले रहे हैं कि क्या एक कॉन्स एफएन का शरीर कानूनी है, लेकिन एक कॉन्स एफएन दिया गया है, यहां हमारे विकल्प "कॉन्स्ट एफएन के कॉलर के साथ क्या कर सकते हैं" जैसी चीजों को निर्धारित नहीं करते हैं। परिणाम", है ना? मैं यह पता लगाने की कोशिश कर रहा हूं कि मैं किस बारे में बात कर रहा हूं उसका एक उदाहरण क्या हो सकता है - मुझे लगता है कि यह होगा कि कॉलर को ठीक से पता नहीं चलेगा कि एनम के कौन से वेरिएंट का उपयोग किया गया था, केवल वह - जो भी मूल्य वापस कर दिया गया था - इसमें आंतरिक परिवर्तनशीलता नहीं थी (जो कि वे संभवतः मिलान करते समय भरोसा नहीं कर सकते हैं, या तो, तब से)।

दूसरे शब्दों में, हम यह निर्धारित करने के लिए उपयोग किए गए विश्लेषण पर निर्णय ले रहे हैं कि क्या एक कॉन्स एफएन का शरीर कानूनी है, लेकिन एक कॉन्स एफएन दिया गया है, यहां हमारे विकल्प "कॉन्स्ट एफएन के कॉलर के साथ क्या कर सकते हैं" जैसी चीजों को निर्धारित नहीं करते हैं। परिणाम", है ना? मैं यह पता लगाने की कोशिश कर रहा हूं कि मैं किस बारे में बात कर रहा हूं उसका एक उदाहरण क्या हो सकता है - मुझे लगता है कि यह होगा कि कॉलर को ठीक से पता नहीं चलेगा कि एनम के कौन से वेरिएंट का उपयोग किया गया था, केवल वह - जो भी मूल्य वापस कर दिया गया था - इसमें आंतरिक परिवर्तनशीलता नहीं थी (जो कि वे संभवतः मिलान करते समय भरोसा नहीं कर सकते हैं, या तो, तब से)।

हाँ, const fn का शरीर अपारदर्शी होता है। यह एक const आइटम के इंटिलाइज़र एक्सप्रेशन के विपरीत है। आप इसे इस तथ्य से देख सकते हैं कि

const FOO: Option<Cell<i32>> = None;

एक &'static Option<Cell<i32>> बनाने के लिए इस्तेमाल किया जा सकता है

const BAR: &'static Option<Cell<i32>> = &FOO;

जबकि एक ही शरीर के साथ एक const fn नहीं कर सकता:

const fn foo() -> Option<Cell<i32>> { None }
const BAR: &'static Option<Cell<i32>> = &foo();

खेल का मैदान डेमो

जब हम स्थिरांक पर नियंत्रण प्रवाह का परिचय देते हैं, तो इसका मतलब है कि

const FOO: Option<Cell<i32>> = if MEH { None } else { None };

भी काम करेगा, MEH के मूल्य के अप्रासंगिक और

const FOO: Option<Cell<i32>> = if MEH { Some(Cell::new(42)) } else { None };

काम नहीं करेगा, फिर से, MEH के मूल्य के अप्रासंगिक।

नियंत्रण प्रवाह const fn की कॉल साइटों के बारे में कुछ भी नहीं बदलता है, बस उस कॉन्स fn के अंदर किस कोड की अनुमति है।

रेपो में कुछ प्रतिनिधि परीक्षणों के लिंक, ताकि हम व्यवहार का निरीक्षण कर सकें।

मैंने "करंट नाइटली सिमेंटिक्स" खंड के अंत में एक पैराग्राफ जोड़ा जो कुछ दिलचस्प परीक्षण मामलों से जुड़ा है। मुझे लगता है कि हमें और अधिक परीक्षणों की आवश्यकता है (एक बयान जो परिस्थितियों की परवाह किए बिना सच है) इससे पहले कि यह स्थिर हो जाए, लेकिन एक बार जब हम यह तय कर लें कि वर्तमान शब्दार्थ वांछनीय हैं या नहीं, तो इसे संबोधित किया जा सकता है।

चाहे सेवर के आसपास निहितार्थ हों या कुछ और।

ऊपर @ ओली-ओबीके ने जो कहा है, उसके अलावा, मैं यह बताना चाहता हूं कि const के अंतिम मूल्य को बदलना तकनीकी रूप से पहले से ही एक सेवर-ब्रेकिंग परिवर्तन है:

// Upstream crate
const IDX: usize = 1; // Changing this to `3` will break downstream code!

// Downstream crate

extern crate upstream;

const X: i32 = [0, 1, 2][upstream::IDX]; // Only compiles if `upstream::IDX <= 2`

हालांकि, क्योंकि हम पूर्ण सटीकता के साथ कॉन्स्टेबल योग्यता नहीं कर सकते हैं, if या match का उपयोग करने के लिए स्थिरांक को बदलने से डाउनस्ट्रीम कोड टूट सकता है , भले ही अंतिम मान में परिवर्तन न हो। उदाहरण के लिए:

// Changing from `cfg` attributes...

#[cfg(not(FALSE))]
const X: Option<Vec<i32>> = None;
#[cfg(FALSE)]
const X: Option<Vec<i32>> = Some(Vec::new());

// ...to the `cfg` macro...

const X: Option<Vec<i32>> = if !cfg!(FALSE) { None } else { Some(Vec::new() };

// ...could break downstream crates, even though `X` is still `None`!

// Downstream

 // Only legal if static analysis can prove the qualifications in `X`
const _: () =  std::mem::drop(upstream::X); 

यह const fn के मुख्य भाग में होने वाले परिवर्तनों पर लागू नहीं होता है, क्योंकि हम हमेशा वापसी मूल्य के लिए टाइप-आधारित योग्यता का उपयोग करते हैं, यहां तक ​​कि एक ही क्रेट के भीतर भी।

मेरे विचार में, यहां "मूल पाप" const और बाहरी क्रेट में परिभाषित static s के लिए टाइप-आधारित योग्यता पर वापस नहीं आ रहा था। हालांकि, मेरा मानना ​​​​है कि 1.0 के बाद से ऐसा ही है, और मुझे संदेह है कि इस पर काफी कोड निर्भर करता है। जैसे ही आप कॉन्स इनिशियलाइज़र को अनुमति देते हैं जिसके लिए स्थैतिक विश्लेषण पूरी तरह से सटीक नहीं हो सकता है, उन इनिशियलाइज़र को इस तरह से संशोधित करना संभव हो जाता है कि वे स्थिर विश्लेषण के बिना इसे साबित करने में सक्षम होने के बिना समान मूल्य का उत्पादन करेंगे।

संपादित करें:

इस संबंध में if और match बारे में कुछ भी अनोखा नहीं है। उदाहरण के लिए, यदि डाउनस्ट्रीम टोकरा मूल्य-आधारित योग्यता पर निर्भर था, तो वर्तमान में const इनिशियलाइज़र को const fn बदलने के लिए यह एक ब्रेकिंग परिवर्तन है।

// Upstream
const fn none<T>() -> Option<T> { None }

const VALUE_BASED: Option<Vec<i32>> = None;
const TYPE_BASED: Option<Vec<i32>> = none();

// Downstream

const OK: () = { std::mem::drop(upstream::VALUE_BASED); };
const ERROR: () = { std::mem::drop(upstream::TYPE_BASED); };

@ परमानंद-मोर्स स्थिरीकरण रिपोर्ट लिखने के लिए धन्यवाद! आइए आम सहमति को अतुल्यकालिक रूप से मापें:

@rfcbot मर्ज

यदि कोई इस पर बैठक में समकालिक रूप से चर्चा करना चाहता है, तो कृपया पुनः नामांकित करें।

टीम के सदस्य @joshtriplett ने इसे मर्ज करने का प्रस्ताव दिया है। अगला चरण बाकी टैग की गई टीम के सदस्यों द्वारा समीक्षा है:

• [एक्स] @ क्रैमर्टज
• [x] @joshtriplett
• [x] @nikomatsakis
• [x] @pkfelix
• [ ] @scottmcm
• [ ] @ नावों के बिना

वर्तमान में कोई चिंता सूचीबद्ध नहीं है।

एक बार जब अधिकांश समीक्षक स्वीकृति दे देते हैं (और अधिकतम 2 अनुमोदन बकाया हैं), तो यह अपनी अंतिम टिप्पणी अवधि में प्रवेश करेगा। यदि आपको कोई बड़ा मुद्दा मिलता है जिसे इस प्रक्रिया में किसी भी बिंदु पर नहीं उठाया गया है, तो कृपया बोलें!

टैग की गई टीम के सदस्य मुझे क्या आदेश दे सकते हैं, इस बारे में जानकारी के लिए

:घंटी: उपरोक्त समीक्षा के अनुसार, यह अब अपनी अंतिम टिप्पणी अवधि में प्रवेश कर रहा है । घंटी:

क्या यह ? में const fn का उपयोग करने की भी अनुमति देता है?

यह नहीं करता है । const fn में सामान्य

? का उपयोग करने का अर्थ है Try विशेषता का उपयोग करना। const fn में लक्षणों का उपयोग करना अस्थिर है, https://github.com/rust-lang/rust/issues/67794 देखें।

@TimDiekmann कुछ समय के लिए, आपको loop और for , कम से कम एक निश्चित सीमा तक (आदिम रिकर्सन शैली) लेकिन const eval में वैसे भी ऐसी सीमाएं होती हैं। यह सुविधा बहुत बढ़िया है, यह बहुत सी चीजें सक्षम करती है जो पहले संभव नहीं थी। आप चाहें तो const fn में एक छोटा wasm vm भी बना सकते हैं।

उपरोक्त समीक्षा के अनुसार, विलय के स्वभाव के साथ अंतिम टिप्पणी अवधि अब पूरी हो गई है ।

शासन प्रक्रिया के स्वचालित प्रतिनिधि के रूप में, मैं लेखक को उनके काम के लिए और योगदान देने वाले सभी लोगों को धन्यवाद देना चाहता हूं।

आरएफसी का जल्द ही विलय किया जाएगा।