Rust: रस्ट को एम्स्क्रिप्टेन के साथ काम करें

#3608 भी देखें।

अभी भी अच्छा होगा; किसी परिपक्वता मील के पत्थर पर नहीं।

अभी भी अच्छा होगा, लेकिन यह बहुत महत्वपूर्ण नहीं है। यह आसान होना चाहिए, क्योंकि जंग में बहुत सारे रनटाइम को फिर से लिखा जा रहा है।

यह भी देखें https://github.com/mozilla/rust/issues/7282

अब जबकि रनटाइम रस्ट में लिखा गया है, यह इस बग के लिए संभावनाओं को कैसे बदलता है? एक रनटाइमलेस हैलो वर्ल्ड को एमस्क्रिप्टन के माध्यम से चलाना कितना कठिन होगा?

देखो

• https://github.com/thestinger/rust-core
• https://gist.github.com/klutzy/7819231

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

एक बार 1:1 शेड्यूलिंग मोड थोड़ा और परिपक्व हो जाने पर हम वेब वर्कर्स के माध्यम से कार्यों के लिए समर्थन जोड़ने में सक्षम हो सकते हैं, हालांकि वर्तमान में इसके लिए एक अलग संदेश पासिंग समाधान की आवश्यकता होगी। जेएस/एम्सस्क्रिप्टन में समांतरता समर्थन क्या जोड़ा जाता है इसके आधार पर हम अंततः जंग के संदेश को अर्थशास्त्र से गुजरने का समर्थन करने में सक्षम हो सकते हैं।

@brson : मुझे लगता है कि #10780 इस समय सबसे बड़ा अवरोधक होगा। जंग एलएलवीएम के खंडित स्टैक समर्थन के माध्यम से स्टैक सुरक्षा करने के लिए उपयोग किए गए आकार को अद्यतन करने के लिए कॉल के साथ लैंडिंग पैड आउटपुट करेगा।

-Z no-landing-pads के लिए धन्यवाद यह अब ठीक काम करता है! इसके लिए मानक पुस्तकालय में स्पष्ट समर्थन जोड़ना संभव है, लेकिन अधिकांश वैसे भी काम नहीं कर रहे हैं (फाइलें, टीसीपी, यूडीपी, आदि) इसलिए मुझे नहीं लगता कि यह आवश्यक है। यदि और जब मानक पुस्तकालय फ्रीस्टैंडिंग समर्थन प्राप्त करता है, तो यह काम करना शुरू कर देगा और हम कार्यक्षमता के आधार पर और अधिक मुद्दों को खोल सकते हैं जिन्हें हम जावास्क्रिप्ट में मैप कर सकते हैं।

अगर यह ठीक है, तो मैं वास्तव में इसे अभी के लिए खुला छोड़ना चाहूंगा। मुझे लगता है कि ऐसा करना यह सुनिश्चित करने की दिशा में एक अच्छा कदम होगा कि मानक पुस्तकालय एक्स्टेंसिबल है और किसी भी प्लेटफॉर्म पर चलने में सक्षम है।

मैं इस बात से सहमत हूं कि अधिकांश काम संभवत: हो चुका है, और इसके लिए संभवत: libemscripten होगी ताकि एमस्क्रिप्टन-विशिष्ट I/O प्रदान किया जा सके, लेकिन मुझे लगता है कि इस तरह से पर्याप्त स्नैग हिट हो सकते हैं कि यह छोड़ने लायक है मुद्दा खुला है (यह अभी भी एक दिलचस्प परियोजना है!)

@alexcrichton : मानक पुस्तकालय की समरूपता और एमस्क्रिप्टन के लिए I/O समर्थन प्रदान करना संभव नहीं होगा। सबसे अच्छा, यह stdout/stderr के लिए कंसोल पर आउटपुट कर सकता है। मैं मानक पुस्तकालय में किसी भी चीज के बारे में नहीं सोच सकता जो एक ईस्क्रिप्टन लक्ष्य के लिए एक अच्छा विचार होने जा रहा है, लेकिन एक डिफ़ॉल्ट आवंटन कार्यान्वयन से परे एक फ्रीस्टैंडिंग नहीं है।

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

@alexcrichton ने मानक पुस्तकालय को अधिक समझने योग्य निर्भरताओं के साथ छोटे पुस्तकालयों के समूह में

यहां बताया गया है कि मैं इससे निपटने का सुझाव कैसे दूंगा:

• रस्ट और LLVM टूलचेन के साथ कुछ प्रयोग करके यह समझें कि asm.js को क्रॉस-कंपाइल करने के लिए कोडजन कैसे काम करता है।
• मैन्युअल रूप से emscripten के साथ libcore बनाएं और साबित करें कि यह वेब पर काम करता है।
• एक एमस्क्रिप्टन-विशिष्ट लक्ष्य ट्रिपल को समझने के लिए rustc और mk/platform.mk को संशोधित करें, एक क्रॉस-कंपाइल टूलचेन तैयार करें जिसमें libcore.rlib के अलावा कुछ भी नहीं है
• सिस्टम के साथ काम करने की अनुमति देकर liballoc से निपटें (इस मामले में emscripten-प्रदत्त) malloc, फिर अन्य रनटाइम-फ्री क्रेट।

यह काफी अच्छी शुरुआत है!

ठीक है, इसलिए मैंने पहले चरणों के साथ प्रयास किया, और जाहिर तौर पर बल्ले से ही समस्याएं आईं।

मैंने libcore को --emit bc साथ बिटकोड में संकलित किया, और इसे emcc -O0 साथ संकलित करने का प्रयास करते समय, मुझे मिलता है:

/Users/arcnor/emscripten-fastcomp/build/bin/llvm-nm: /tmp/tmpfTkmfj/core_0.o: Invalid CMPXCHG record.
/Users/arcnor/emscripten-fastcomp/build/bin/opt: /tmp/tmpfTkmfj/core.bc: error: Invalid CMPXCHG record
Traceback (most recent call last):
  File "/Users/arcnor/emscripten/emcc", line 1573, in <module>
    shared.Building.llvm_opt(final, link_opts)
  File "/Users/arcnor/emscripten/tools/shared.py", line 1335, in llvm_opt
    assert os.path.exists(target), 'Failed to run llvm optimizations: ' + output
AssertionError: Failed to run llvm optimizations:

सुनिश्चित नहीं है कि मैं इसके बारे में कुछ कर सकता हूं, या ऐसा इसलिए है क्योंकि हम इसके लिए rustc --emit आउटपुट का उपयोग नहीं कर सकते हैं।

क्षमा करें यदि यह इस बारे में टिप्पणी करने का स्थान नहीं है...

मैंने libnum साथ भी कोशिश की, एक और अधिक सरल, और bc सही ढंग से उत्पन्न होता है, लेकिन मुझे emcc प्रक्रिया के दौरान गलत ट्रिपल और परिणामी . js में libnum अंदर कोई भी कार्य नहीं है, इसलिए मुझे लगता है कि मैं यहां बहुत बेवकूफ हूं :)

@Arcnor आप उन लोगों में से कुछ से पूछ सकते हैं जिन्होंने पहले अपनी प्रक्रिया के बारे में emscripten के साथ सरल परीक्षण संकलित किए हैं। मेरे पास केवल कुछ विचार हैं।

• एलएलवीएम बिटकोड संस्करण से संस्करण में बदलता है और रस्ट द्वारा उपयोग किया जाने वाला संस्करण हमेशा एमस्क्रिप्टन जैसा नहीं होता है। एलएलवीएम के अपेक्षाकृत समान संस्करण का उपयोग करके उन दोनों को प्राप्त करने से संगतता में सुधार हो सकता है।
• आपके त्रुटि संदेश से ऐसा प्रतीत होता है कि आप एम्स्क्रिप्टेन के नए 'फास्टकॉम्प' बैकएंड का उपयोग कर रहे हैं। यह उनके पुराने बैकएंड की तुलना में रस्टी वर्कलोड पर कम परीक्षण किया जा सकता है। पुराने बैकएंड को मैन्युअल रूप से चुनने से कम से कम अलग परिणाम मिल सकते हैं।
• एम्सस्क्रिप्टन आम तौर पर अपने स्वयं के लक्ष्य ट्रिपल का उपयोग करता है, इसलिए उसी का उपयोग करने के लिए रस्टसी को पीछा करने की आवश्यकता हो सकती है।

libcore को संकलित करने का प्रयास करते समय त्रुटि इस emscripten समस्या से संबंधित प्रतीत होती है। libcore को llvm बाइटकोड में संकलित करना llvm परमाणु निर्देश उत्पन्न करता है, लेकिन emscripten परमाणु निर्देशों का समर्थन नहीं करता है।

जंग की तरफ से इसके आसपास काम करने का एक तरीका हो सकता है, लेकिन एम्सस्क्रिप्टन मुद्दे में टिप्पणियों के आधार पर मुझे लगता है कि परमाणु में एम्सस्क्रिप्ट के लिए समर्थन प्राप्त करना सबसे अधिक समझ में आता है।

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

अगर मैं गलत नहीं हूं, तो एमस्क्रिप्टन का नया "फास्टकॉम्प" बैकएंड एलएलवीएम का एक कांटा है (जबकि पिछला बैकएंड एलएलवीएम के ऊपर सिर्फ एक परत था), इसलिए फास्टकॉम्प के एलएलवीएम संस्करण को अपग्रेड करना मुश्किल है और इसे अपग्रेड नहीं किया जाएगा। बार बार।

यह समस्याग्रस्त होगा यदि इसे जंग के उत्पादन के साथ संगत होने की आवश्यकता है। उदाहरण के लिए अभी Fastcomp का LLVM संस्करण 3.3 है, जबकि Rust द्वारा उपयोग किया जाने वाला LLVM 3.4 है।

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

मुझे लगता है कि इस समय के लिए एमस्क्रिप्टन के लिए संकलन करने की कोशिश करने वाला एकमात्र व्यक्ति है।

रिकॉर्ड के लिए, मैंने कोशिश की चीजें यहां दी गई हैं:

• बायटेकोड को संकलित करना (रस्ट के एलएलवीएम 3.4 द्वारा उत्पन्न) और इसे फास्टकॉम्प (एलएलवीएम 3.3 का कांटा) में पास करना; Fastcomp क्रैश होने का कारण बनता है
• IR में संकलित करना, इसे मैन्युअल रूप से संपादित करना जब तक कि यह LLVM 3.3 के साथ संगत न हो जाए और इसे fastcomp में पास कर दें; बहुत जटिल, किसी भी गैर-तुच्छ कोड के लिए संशोधित करने के लिए बहुत सी चीजें
• रस्ट स्टेज1 को --llvm-root के साथ संकलित करना emscripten's fastcomp की ओर इशारा करता है; यह काम नहीं किया क्योंकि उन्होंने एआरएम/एमआईपीएस/आदि के लिए समर्थन हटा दिया था। उनके कांटे में (मुझे मेकफ़ाइल से त्रुटियां मिल रही हैं और इस वजह से लिंकेज के दौरान)
• 3.3 युग से एक पुरानी प्रतिबद्धता को इंगित करने के लिए जंग के स्रोत कोड में LLVM git सबमॉड्यूल को संशोधित करें; LLVM में किसी बिंदु पर segfault प्राप्त करना
• --llvm-root साथ रस्ट को संकलित करना एक पूर्व-संकलित LLVM 3.3 (आधिकारिक ubuntu रेपो से आ रहा है) की ओर इशारा करता है; चरण 1 के संकलन के अंत में एक दावा प्राप्त करना विफल हो गया और उत्पादित रस्टसी बाइनरी काम नहीं करता है।

जब तक किसी के पास कोई विचार न हो, मेरा निष्कर्ष यह है कि हमें एम्स्क्रिप्टेन को अपग्रेड करने के लिए प्रतीक्षा करने की आवश्यकता है।

ऐसा लगता है कि रम काम कर रहा है, सॉर्टा; शायद यह मदद करेगा

मामूली अद्यतन: emscripten-fastcomp को LLVM 3.4 में अद्यतन किया गया है, और बाद में LLVM 3.5 में अद्यतन किया जाएगा।

@tomaka क्या आपने 3.4 संस्करण के साथ कुछ भी करने की कोशिश की है? मैं इसके साथ संकलित रम उदाहरण प्राप्त करने में सक्षम था, लेकिन अनजाने में त्रुटियों के साथ कुछ और विफल रहा।

@ibdknox 3.4 3.5 . के साथ असंगत है
यहां तक ​​​​कि एक साधारण हैलो वर्ल्ड भी एक असफल दावा पैदा करता है: LLVM ERROR: 0 && "some i64 thing we can't legalize yet"

हम्म। मैं rustc --emit ir foo.rust से आउटपुट लेने और इसे emscripten-incoming के माध्यम से चलाने में सक्षम था। क्या LLVM 3.5 पर अब जंग लग गई है?

रस्ट लंबे समय से LLVM 3.5 का उपयोग कर रहा है। आप भाग्यशाली हो सकते हैं और कुछ भी असंगत उत्पन्न नहीं हो सकता है।
उदाहरण के लिए यह ठीक संकलित करता है:

#[start]
fn main(_: int, _: *const *const u8) -> int {}

यह असंगत IR के कारण नहीं है:

fn main() { println!("hello world"); }

@ibdknox http://www.reddit.com/r/rust_gamedev/comments/2n0x08/emscripten_experiments/
ऐसा लगता है कि जितना मैंने सोचा था उससे कम असंगतताएं हैं।

एक अद्यतन के रूप में, जब मैं हैलो वर्ल्ड को एम्स्क्रिप्टन के साथ संकलित करता हूं जिसे अब 3.5 में अपडेट किया गया है, तो मुझे निम्न मिल रहा है:

Value:   %28 = call fastcc { i8, [0 x i8], [0 x i8] } @_ZN3fmt5write20h2c56fdda0b308d94DFAE({ i8*, void (i8*)** }* noalias nocapture dereferenceable(8) %arg.i, %"struct.core::fmt::Arguments[#3]"* noalias nocapture readonly dereferenceable(24) %__args31), !noalias !22
LLVM ERROR: Unrecognized struct value
Traceback (most recent call last):
  File "/Users/chris/Downloads/emsdk_portable/emscripten/incoming/emcc", line 1259, in <module>
    shared.Building.llvm_opt(final, link_opts)
  File "/Users/chris/Downloads/emsdk_portable/emscripten/incoming/tools/shared.py", line 1401, in llvm_opt
    assert os.path.exists(target), 'Failed to run llvm optimizations: ' + output
AssertionError: Failed to run llvm optimizations:

यहां बताया गया है कि मैं कैसे संकलन कर रहा हूं:

rustc --target i686-apple-darwin -C lto --emit ir foo.rust
emcc -v foo.ll -o test.html

हालांकि, जो चीजें fmt में नहीं आती हैं, वे आम तौर पर काम करने लगती हैं।

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

इसलिए मुझे लगता है कि मैंने जो कुछ सीखा (लेकिन मुझे ध्यान देने में कुछ शामें लगीं) उस पर ध्यान देने वाली पहली बात यह है कि रस्ट जुलाई में एलएलवीएम 3.6 में चला गया। तो Rust और emscripten-fastcomp के वर्तमान संस्करण असंगत हैं।

मैंने जंग को संकलित करने की कोशिश की --llvm-root के साथ emscripten-fastcomp 1.29.2 की ओर इशारा करते हुए और यह त्रुटि मिली:

rustc: x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib/libcore
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'assertion failed: self.raw.hash != self.hashes_end', /Users/zen/Code/rust/src/libstd/collections/hash/table.rs:776


make: *** [x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib/stamp.core] Error 101

इस त्रुटि को प्राप्त करने के लिए मैंने emscripten-fastcomp को कॉन्फ़िगर और बनाया है

../configure --enable-optimized --disable-assertions --enable-targets=host,js,arm,aarch64,mips

एम्सस्क्रिप्टन गाइड की सिफारिश के बजाय

../configure --enable-optimized --disable-assertions --enable-targets=host,js

हालांकि रस्ट को सभी लक्ष्यों के लिए निर्मित करने की आवश्यकता नहीं है, यह वर्तमान में हमेशा सभी लक्ष्यों के लिए संकलित CPU समर्थन के साथ LLVM के विरुद्ध लिंक करता है। यह किसी समस्या का समाधान है जिसे भविष्य में ठीक किया जा सकता है, इसलिए हमें उस कॉन्फ़िगरेशन के साथ हमेशा emscripten-fastcomp को संकलित करने की आवश्यकता नहीं हो सकती है।

एक बार जब मैंने पाया कि जंग एलएलवीएम 3.6 में चली गई है तो मैंने जंग-लैंग/एलएलवीएम पर आखिरी शाखा देखी जो एलएलवीएम 3.5 थी। https://github.com/rust-lang/llvm/tree/rust-llvm-2014-07-24 मैंने इसके बजाय emscripten-fastcomp के खिलाफ संकलित किया, यह देखने के लिए उत्सुक था कि क्या निकलेगा। मुझे वही सटीक त्रुटि मिली जब एम्सस्क्रिप्टन-फास्टकॉम्प के हालिया कदम को एलएलवीएम 3.5 में संकलित किया गया। मैं इसका मतलब यह लेता हूं कि जंग किसी तरह से अब एलएलवीएम 3.5 के साथ असंगत है और मैं वास्तव में अन्यथा उम्मीद नहीं करता।

तो अब हम प्रतीक्षा करें या LLVM 3.6 :wink करने के लिए emscripten-fastcomp प्राप्त करें:

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

मैंने रस्ट-लैंग/एलएलवीएम को एम्स्क्रिप्टेन-फास्टकॉम्प में विलय करने पर एक नज़र डाली। उस समय 43 फाइलों पर 117 परस्पर विरोधी धाराएं थीं।

मैंने लिंकिंग चरण में जाने के लिए Rust 0.11 और emcc 1.29.2 प्राप्त करने का उल्लेख किया है। यह विशिष्ट परिणाम है:

$ emcc -v hello.ll -o hello.js
INFO     root: (Emscripten: Running sanity checks)
WARNING: Linking two modules of different data layouts: '/Users/zen/.emscripten_cache/libc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas '/tmp/tmpv_yB8E/hello_0.o' is 'e-p:32:32-f64:32:64-f80:128-n8:16:32'
WARNING: Linking two modules of different target triples: /Users/zen/.emscripten_cache/libc.bc' is 'asmjs-unknown-emscripten' whereas '/tmp/tmpv_yB8E/hello_0.o' is 'i686-apple-darwin'
warning: incorrect target triple 'i686-apple-darwin' (did you use emcc/em++ on all source files and not clang directly?)
warning: unresolved symbol: _ZN2io5stdio12println_args20h0caae70b0e2eb347Iol7v0_11_0E
warning: unresolved symbol: _ZN10lang_start20h70f93b7d0a75f99atre7v0_11_0E

ऐसा लगता है कि emcc/fastcomp अंडरस्कोर के साथ प्रतीकों में डॉट्स की जगह लेता है जबकि रस्ट दूसरे अंडरस्कोर के साथ उपसर्ग करने की अपेक्षा करता है, लेकिन मैं इसके बारे में निश्चित नहीं हूं। i686-ऐप्पल-डार्विन बिल्ड में libstd में पहला अनसुलझा प्रतीक __ZN2io5stdio12println_args20h0caae70b0e2eb347Iol7v0.11.0E रूप में प्रकट होता है। यहां तक ​​​​कि अगर मैं यह जानने के लिए emcc प्राप्त कर सकता हूं कि निर्मित पुस्तकालयों में इस प्रतीक को कैसे खोजा जाए, तो मैं अनुमान लगा रहा हूं कि libs में मशीन कोड होता है जबकि emcc को LLVM बाइट कोड की आवश्यकता होगी। मुझे लगता है कि मुझे याद है कि किसी ने एमस्क्रिप्टन के लिए मानक पुस्तकालय को संकलित करने की आवश्यकता का उल्लेख किया है। यह उसकी जरूरत का हिस्सा होगा।

तो यहां अगले चरण हैं जिन्हें मैं कोशिश कर रहा हूं और काम कर रहा हूं अगर कोई खुद पर एक शॉट लेना चाहता है। (या मुझे बता सकते हैं कि मैं कितना सही या गलत हूं।)

• रस्ट-लैंग/एलएलवीएम को एम्स्क्रिप्टेन-फास्टकंप में मिलाएं
• जेएस बैकएंड सपोर्ट के बिना मर्ज किए गए फास्टकॉम्प के साथ जंग बनाएं
  उम्मीद है कि यह विलय के लिए एक अच्छा विवेक परीक्षण होगा।
• रस्ट में एमस्क्रिप्टेन का ट्रिपल जोड़ें और इसे बनाएं
  मैं जो बता सकता हूं उससे कई फाइलें हैं जिन्हें मुझे बदलने या जोड़ने की जरूरत है।
  
  
  
  • mk/cfg/asmjs-अज्ञात-emscripten.mk
  
  
  • rt/arch/asmjs/{morestack.S,record_sp.S} (खाली हो सकता है?)
    
    एलएलवीएम के खंडित स्टैक का समर्थन करने के लिए जंग के लिए मोरेस्टैक बनाने के लिए इन फाइलों की आवश्यकता है। अगर मैं सही ढंग से याद करूं तो एम्सस्क्रिप्टन का ढेर भी सिर है। यह ढेर के विपरीत छोर को ढेर के रूप में उपयोग करता है और चूंकि asmjs के लिए आप सरणी के आकार को नहीं बदल सकते हैं, नए स्टैक सेगमेंट बनाना संभव नहीं है। मैंने librustc_back लक्ष्य फ़ाइलों में लक्ष्य विकल्प में एक फ़ील्ड देखा जो उम्मीद है कि इसे अक्षम कर सकता है।
  
  
  • librustc_trans/trans/cabi_asmjs.rs
  
  
  • librustc_trans/trans/cabi.rs
    
    मुझे यकीन नहीं है कि इनकी आवश्यकता होगी, वर्तमान में केवल एक अनुमान है।
  
  
  • librustc_back/target/asmjs_unknown_emscripten.rs
  
  
  • librustc_back/asmjs.rs
  
  
  • librustc_syntax/abi.rs
  
  
  • librustc_back/back/write.js config_llvm ()
  
  
  • librustc_llvm/lib.rs static_link_hack_this_sucks ()
  
  
• लापता सिस्टम इंटरफेस को लागू करें
  मैंने नवंबर में देखा था कि लिबग्रीन को हटा दिया गया था। चूंकि एम्स्क्रिप्टन को ब्राउज़र में श्रमिकों के साथ साझा करने के लिए किसी तरह की प्रतीक्षा करने की आवश्यकता होती है, अगर ऐसा कभी होता है, तो लिबग्रीन जैसी किसी चीज़ को पुनर्स्थापित करने की आवश्यकता होगी या विशेष रूप से एम्स्क्रिप्टेन के लिए कुछ फैशन में पर्थ्रेड को शिम किया जाना चाहिए जैसे कि पर्थ्रेड या विंडोज़ थ्रेड एपीआई के लिए जंग कैसे बनता है।

आईओ भी। शायद अन्य भागों से मैं अनजान हूँ।

"रस्ट-लैंग/एलएलवीएम को एम्सस्क्रिप्टन-फास्टकॉम्प में मिलाएं"

आप शायद ऐसा नहीं करना चाहें - Emscripten pnacl-llvm/pnacl-clang पर आधारित है, इसलिए आप पैच पर पैच के साथ एक कांटा बना रहे हैं, जो शायद दर्दनाक होगा। यदि आप रुचि रखते हैं, तो आप r33 -> r34 से https://github.com/kripken/emscripten-fastcomp/issues/51#issuecomment -62323164 पर एम्सस्क्रिप्टन मर्ज के लिए किए गए जांच में ब्रांचिंग के कुछ विवरण देख सकते हैं। .

मैंने सुना है कि pnacl पहले की तुलना में अपस्ट्रीम को थोड़ा करीब से ट्रैक करने की योजना बना रहा है, लेकिन मैं pnacl इश्यू ट्रैकर में 3.6 को अपडेट करने के लिए कोई प्रासंगिक समस्या नहीं देख सकता, इसलिए यह कुछ समय हो सकता है (विशेषकर 3.6 केवल 5 दिन पहले ब्रांच किया गया!)। ..मुझे लगता है कि आप एक मुद्दा बना सकते हैं? यदि आप अपने स्वयं के Emscripten कांटे के विरुद्ध निर्णय लेते हैं, तो मुझे दो विकल्प दिखाई देते हैं - pnacl की प्रतीक्षा करना या Emscripten को pnacl से और अपस्ट्रीम पर जाने में मदद करना।

संपादित करें: 'अभी' को 'नहीं' में सही किया गया। एक महत्वपूर्ण अंतर।

मैं 1.0 के लिए हमें तैयार करने के लिए बड़े पैमाने पर ट्राइएज प्रयास कर रहा हूं। इसके भाग के रूप में, मैं इच्छा-सूची वाली सामग्री को RFCs रेपो की तरह स्थानांतरित कर रहा हूं, क्योंकि यहीं पर प्रमुख नई चीजों पर चर्चा/प्राथमिकता दी जानी चाहिए।

इस मुद्दे को RFCs रेपो में ले जाया गया है: rust-lang/rfcs#604