Rust: Fastcompなしでasm.jsとWebAssemblyをサポートするための追跡の問題

@tlively私は＃42420もこれの一部になると思いますか？ もしそうなら、それをリストに追加できますか？

@ est31 ＃42420がこの一部である理由がわかりません。 NaCl / PNaClのサポートはFastcompにも依存していますか？

@tlively私はLLVMの専門家ではありませんが、錆のLLVMのフォークを調べると、 lib/Target/JSBackend/NaCl/がNaClバックエンドを見つけることができる場所ですが、上流のLLVMにはJSBackendサブディレクトリがまったくないようです。 また、上流のLLVMでNaClへの意味のある参照が見つからないため、移動されませんでした。 fastcompによる追加のようです。

確認できます-JavaScriptバックエンド全体がlib/Target/JSBackend/ます。

このディレクトリ外のLLVMに対するJS固有の変更はすべて、次のように装飾されています。

@LOCALMOD-BEGIN
< .. js specific code .. >
@LOCALMOD-END

fastcompによる追加のようです。

です

cc＃45905

（https://github.com/rust-lang/rust/pull/45905からの継続的な議論）

@RReverser

@pepyakin少なくともNode.js側のスポーンプロセスでは、ネットなどは非常に簡単に実装できます。 パスの文字は、ホストシステムなどから取得できます。 @badboyが提案したように、これにEmscriptenライブラリを再利用して実験することは理にかなっていると思います。

しかし、Webバージョンはどうすればよいでしょうか。 JSでfs、net、envなどのエミュレーションを実装する必要がありますか？ それともトラップする必要がありますか？ エミュレーションを実装することを選択した場合は、実行している「サブ環境」に応じて「実際の」APIまたはエミュレートされたAPIを呼び出すJSシムライブラリが必要になります。 しかし、ユーザーが1つの「サブ環境」のみを実行したい場合はどうなるでしょうか。 または、ユーザーはfsまたはnetのいずれか、あるいは何も望んでいませんか？
Emscriptenは、JSファイルの前処理でこの問題を解決します。 独自の前処理を行う必要がありますか？
しかし、私たちはすべきですか？ すでに仕事をしているemscriptenがあるとすると？

wasmのアプリケーションは、本当にWebを超えてがあります。 高速で安全かつ決定論的な実行は、かなり望ましい特性のようです。

• IoT、
• プラグイン、スクリプト、およびその他の大規模なプログラムへの埋め込み、
• 決定論的実行、特にp2p（つまり、ブロックチェーンアプリケーション）の場合、
• ユニバーサルドライバー、
• モバイルアプリ、
• デスクトップおよびサーバーアプリ、

一部の環境では、完全なstd実装できます。 ただし、他の人はできません。
これらの機能はサポートできる場合とできない場合があります。

• プロセス、
• ファイルシステム、
• TCP / UDP、
• 環境変数、
• stdin、stdout
• 等...

すべてのWASM機能が常に望まれるわけではありません（パフォーマンス上の理由および/または決定論的実行の必要性のため）：

• スレッド🦄、
• gc🦄、
• simd🦄、
• フローティングポイント、
• 成長する記憶、

これにより、wasmはエンドユーザープラットフォームというよりもISAに似たものになると思います。 （言うまでもなく、JS / WebとJS / Nodeの組み合わせにも問題があります）。

このすべての動物園を適切に処理するには、ポータビリティリントのようなものと、おそらくこのストローマンのようないくつかのトリプルが必要だと思います。

• wasm32-unknown-unknown -環境について何も想定しない一般的なターゲット。 ウェブに適しています。
• wasm32-unknown-node -ノード専用のターゲット。 私はそれがすべての標準をサポートするかもしれないと思いますか？

他の環境では、必要に応じて、これらのシステムバインディングの独自の実装を提供する場合があります。

それは携帯性のリントを役に立たなくしますね？

私はまだwasm32-unknown-unknownが最低限のものを提供すること（それが理にかなっている場合はlibstdを使用）が私たちに長い道のりをもたらすと思います。

しかし、Webバージョンはどうすればよいでしょうか。 JSでfs、net、envなどのエミュレーションを実装する必要がありますか？ それともトラップする必要がありますか？

これらのことのためにシムを実装する必要があります。

エミュレーションを実装することを選択した場合は、実行している「サブ環境」に応じて「実際の」APIまたはエミュレートされたAPIを呼び出すJSシムライブラリが必要になります。

はい、このシムが必要になります。 これは、今日のEmscriptenで機能するのと同じです。

しかし、ユーザーが1つの「サブ環境」のみを実行したい場合はどうなるでしょうか。

これらのさまざまなものをモジュール化できる場合は、wasmモジュールをロードする前に必要なものをロードするのはユーザーの責任です（繰り返しますが、Emscriptenのシムについてはまだ調べていませんが、それらを抽出するのは簡単です）。
これは、Rust自体の一部である必要はありません。
しかし、私はまた、この環境を提供する必要がある、または提供したいすべてのモジュールを期待していません（JavaScript <-> Wasmの相互作用は、実行全体でまだ遅いものです）。

（私は今その移植性lintRFCを読むつもりです）

私はまだwasm32-unknown-unknownが最低限のものを提供すること（それが理にかなっている場合はlibstdを使用）が私たちに長い道のりをもたらすと思います。

私もこれに同意します。 しかし、「ベアミニマム」の意味については意見が分かれているようです:)私にとって、「ベアミニマム」にはfs、net、processes、rngなどは含まれていません。

これは、今日のEmscriptenで機能するのと同じです。

これは、Rust自体の一部である必要はありません。

OK、ここに私の直接の質問があります：Web、Nodeをサポートする本格的なstdライブラリが必要な場合、なぜEmscriptenを使用しないのですか？ 😃

IMO、 wasm32-unknown-unknownはシムがないはずです。 wasm32-unknown-webは、より大きな機能のチャンクのためのシムを備えた、emscriptenのようなものになります。

wasmの非Webアプリケーションはシムを必要とせず、シムを使用しないコードはシムを必要としません。 最小値を小さく保ち、そこから構築します、IMO。

wasm32-unknown-unknown stdクレートがあり、ほとんどのAPIが「サポートされていない」エラーを返すのではなく、 stdがまったくない可能性がありますか？ 「純粋な」wasmでサポートされている機能がstdある場合、この機能がlibcoreやliballocなどの別のクレートに属していることを示しているのではないでしょうか。

@SimonSapinええ、多分。

私の頭に浮かぶのはスレッドです。

WASMスレッドのプロポーザル（ただし、まだWIPです）は、 atomic.wakeとatomic.wait操作を追加することを提案しています。これは、おおよそthread::park / Condvarます。

もう1つのポイントがあります。それは、 libcore観点からのみ実装でき、 liballoc自動的にlibstdに入るということです。 たとえば、 io::Readとio::Writeです。
純粋なwasmコンテキストでのそれらの使用法を想像することができます。

また、十分に目を細めれば、stdの外でのHashMap実装を想像することができます。

もう1つのポイントがあります。libcoreとliballocの観点からのみ実装できるものは、自動的にlibstdに入ります。 たとえば、io :: Readとio :: Writeです。

liballocはlibcoreに依存しているので、両方に依存することはlibstdに物事を置く十分な理由ではないと思います。 io::Readとio::Write場合、おそらくOSエラーのstd::sysに依存するio::Errorに依存しているためです。

HashMapに関しては、liballocにない理由は、デフォルトのハッシャーでOSから疑似乱数ジェネレーターをシードする必要があるためだと思います。

HashMapはハッシャーにとらわれず、liballocに常駐していると便利です。

liballocはlibcoreに依存しているので、両方に依存することはlibstdに物事を置く十分な理由ではないと思います。 io :: Readとio :: Writeの場合は、OSエラーをstd :: sysに依存するio :: Errorに依存しているためと考えられます。

ああなるほど。 それは残念です。

HashMapに関しては、liballocにない理由は、デフォルトのハッシャーでOSから疑似乱数ジェネレーターをシードする必要があるためだと思います。

その点で@NikVolfに同意する

typeアイテムがデフォルトのタイプパラメータ（ HashMap 、 S = RandomState ）を指定できるかどうかはわかりませんが、それでもオーバーライドできます。

@simonsapin stdのpub type HashMap<K, V, S = RandomState> = core::HashMap<K, V, S>ようなものが機能すると思います（コアバリアントにはデフォルトがありません）。

それは次のようになりますallocではなくcoreが、ええ、それはうまくいくかもしれません。 誰がPRを提出したいと思いますか？ :)

@pepyakin

OK、ここに私の直接の質問があります：Web、Nodeをサポートする本格的なstdライブラリが必要な場合、なぜEmscriptenを使用しないのですか？ 😃

私にとって、Emscriptenを使用しない理由は、ライブラリのためではなく、ツールチェーンの構築における重複と複雑さを回避するためです。 反対に、Node.js / Webで動作するネイティブAPIのエミュレーションを持つことは、完全にネイティブなアプリやライブラリを作成し、面倒なことなくさまざまな環境で実行できるため、Emscriptenの最もエキサイティングな部分です。

私にとって、Emacriptenを使用しない理由は、ライブラリのためではなく、ツールチェーンの構築における重複と複雑さを回避するためです。

重複と複雑さの部分について詳しく説明していただけますか？

重複と複雑さの部分について詳しく説明していただけますか？

これは、Rustを直接使用できる場合にRustとEmscriptenの両方にLLVMが存在することに関するものです（Rustの-emscripten-ターゲットを使用する場合は、現在、両方のLLVMバージョンの互換性を維持する必要があります）。

また、Emscriptenの進化は非常に遅く、私の経験では貢献するのが難しいため、WASM / JS出力にRust固有のものを実装する必要がある場合、Emscripten側で実装しようとすると、すべてを持っている場合よりもはるかに時間がかかる可能性がありますRust側でのみ実行されます。

Web以外のWASMバックエンドの作成者としてここに2セントを落とします。EmscriptenとJSemulがRustの関心事である必要があるという考えは外れています。 WASMコミュニティは集まって、バックエンドがサポートできるlibc風の抽象化セットを作成する必要があります（emscriptenやmineなど）。 それまでの間、特定のバックエンド（JS / Web）の低レベルのimplがRustlangの一部にならないようにしたいと思います。 シムがすでに存在していることで十分です。 JSサポートが必要な場合は、言語の外部の別の場所で実行してください。

@ chpio-ええと、抽象化は実際には重要ではありません。 emscriptenが私が気にするすべてのことに対して行うように、それはちょうどnixシステムコールである可能性があります。 WASMが期待するものをインポートし、バックエンドにそれらを埋めさせるだけですが、もちろん、一貫した抽象化があればよいでしょう。 しかし、本当に素晴らしいことは、すべてのWASMフロントエンドが共有するものを定義できる場合ですが、それはありそうにないようです（Emscriptenは基本的にlibcや他のlibを使用してこれを想定しています）。

stdlibのJS形式を実装することは、Rust-langリポジトリ（またはコア開発者の懸念）の一部であってはならないという私の意見をここに投げました。 私はまだunknown-unknownコンパイルターゲットでプレイしていませんが、1つの方法は、すべての抽象化された関数から発行された個別のwasmファイルを作成し、すべての関数の唯一のコマンドとして到達不能にすることです。 次に、それを実際のwasmファイルにインポートします...必要に応じて、バックエンドの作成者が置き換えることができます。

stdlibのJSフォームを実装する

ええ、明らかにどちらの方法でも、RustはJS側の実装の詳細を知らないので、私が気にしているのは、別のnpmパッケージにすることができます。 ここで重要なのは、呼び出しを行うことです。呼び出しは、使用するターゲット（JSか非JSかを問わず）に関係なく必要であり、同じです。

https://www.tockos.org/blog/2017/crates-are-not-safe/#usage -of-the-standard-library-is-pervasive

Tockに使用する依存関係には、コンパイラが標準ライブラリを含めないように、＃！[no_std]を含める必要があります。 再度、crates.ioですべてのクレートを調査したところ、クレートの93％（11488/12360）が標準ライブラリを使用していることがわかりました（つまり、＃！[no_std]がありません）。 [...]ただし、必要な依存関係を含めると、その数は97％（12023/12360）に増加します。

やあみんな！ これに関する現在のすべての議論を見るのはエキサイティングです！ 私も自分の視点を取り入れることができると思いました。

wasm32-unknown-unknown未来

全体として、私はこの目標がどのように形作られているかに非常に満足しています。 標準ライブラリの大きなチャンク（別名libcore + liballoc）にアクセスできます。今後の提案では、たとえばCondvarようなタイプの実装の入力を開始できると思います（さまざまなwasm命令を使用してMutex ）と同様に。

私が今日知っている「大きな使用法」に対する最大の阻害要因は、コンパイル時間が非常に遅く、最適化を使用してコンパイルしないと、大量のLLVMアサートが発生するという事実です。 「犬の遅い」コンパイル時間は、すべての人にLTOを強制し（wheee！）、lldで修正されるためです。 lldのWebAssemblyサポートはアップストリームでlld自体にマージされましたが、残念ながら、今日ではそれほど遠くは

もっと広く言えば、wasmターゲットが外の世界とどのように相互作用するかを正確に感じることもやや不快です。 たとえば、 extern { fn foo(); }から来ることを必要とされるenvモジュールが、おそらくenv 、設定があるはず？ 他にもさまざまな要素がありますが、一般的に、これを今すぐ使用しようとしている人は、少なくともこれらの問題と、これらの正確な統合/露出の詳細によってターゲットが将来どのように調整されるかを知っていることをお勧めします。

wasmlibstdの未来

src/libstd/sys/wasm/*.rsから返されるすべてのエラーについては特に満足していません。 std::{thread, fs, net}ようなモジュールはwasmターゲットに存在すべきではないと思います。 残念ながら、これを可能にする主要な要素である移植性リントは現在実装されていません。 さらに、libstdがそのような組織（スライスとダイシング）の準備ができているかどうかはまだわかりませんが、移植性のリントともっと話し合うことができるでしょう。 それまでの間、「どこでもエラーを返す」ことが今日の最善の解決策だと思います。

また、このようなモジュールについては特に満足していません。 それと、LLVMによって1.0 % bがfmod下がる可能性があります。 これらの種類の機能は、かなり残念なことに、wasmモジュールをインスタンス化するときにサイレントにインポートを必要とする場合があります。

一般に、標準ライブラリでは、インスタンス化者としてのあなたが心配する必要のないものをインポートする手段はありません。 たとえば、 use std::threadと言うとき、それがたくさんのものをインポートすることを気にする必要はありません。 同様に、JSでMath.tan呼び出しとしてf64::tanを実装することにした場合、理想的にはそれについても心配する必要はありません。

残念ながら、利用できるオプションは多くないと思います。 ある日、wasmは本格的なJSモジュールの市民かもしれないように思えますが、それまでは、依存関係を可能な限りスリムに保つ必要があると思います。 そうすれば、wasmモジュールをインスタンス化するユーザーは、インスタンス化するために提供する必要ができるだけ少なくなります。

Wasm +ノード/ウェブ

個人的には、今ここでは何もできないと思います。 基本的には、実際に定義することを強制せずに何もインポートできないという上記の理由によるものです。 つまり、ノードで実行していることを知っていたとしても、アクセスできる新しい超大国があるわけではありません。

おそらく最終的には、機能を直接インポートできるようになると、2つのターゲットが理にかなっていると思います。 たとえば、ノードターゲットは、 println!ようなものをデフォルトで実際に機能させることができます（これは素晴らしいことです）。

Wasmパイプライン

ただし、このインポートの問題に対する1つの可能な解決策は、ある種の標準パイプラインである可能性があります。 バイナリサイズを気にする場合は、近い将来の標準パイプラインにwasm-gcを含める必要があると思います（不要なcompiler-rt gooを削除するため）。 また、Binaryenツールキットのwasm-optも、 wasm-gc後でコードサイズをさらに縮小できるため、標準パイプラインのメンバーになりたいと思います。

輸出入を扱うパイプラインなどがあるのではないでしょうか。 何もしなくても、 Math.randomをHashMap::new()に自動的に接続できるとしたらどうでしょうか。 それはきちんとしているでしょうが、残念ながらそれが100％可能であるかどうかも完全にはわかりません。

他の人が考えているかどうか知りたいです！

そうそう、Emscriptenのターゲットがすぐになくなることはないとも言えます。 既存のアプリケーションを移植する場合でも、これらすべてのエミュレーションレイヤーが本当に必要なので、これらは非常に便利です。 たぶん10年以内に、Emscriptenを使用している人がいなければ、それらを削除できますが、今のところ、Emscriptenには、今日と同じようにサポートし続ける必要がある十分なニッチがあると思います。

2セント。
env固定することは、大したIMOではなく、磨くだけです。 これは、数学などを簡単に一括インポートできないことを意味します。 問題に関する古いリンク（半）。 webasemblyテーブルと対話できると、動的に割り当てられた関数で速度が少し向上します。

スレッドは間に合うようになります（あまり多くないことを望んでいます）。私の考え（どこにも読まれない）は、メインインスタンスのスレッドだけがインポートを呼び出すことができるということです。

wasm32-unknow-unknownが最小限であることが大好きです。 println!およびその他のlibstdアイテムの取得に関して：おそらく解決策は、プログラマーが独自の構造を提供できるバックエンドトレイトを公開することです（デフォルトのものをコピーする/クレートを含める）。

デバッグは問題点です。 「ランタイムエラー：到達不能が実行されました」このメッセージは理想的にはより良いはずです。
スタックトレース：wasm-function [55] @これを読んで、Firefoxがそれを使用するかどうかはわかりませんが、無駄にデバッグについての言及はありません。

何もしなくても、Math.randomをHashMap :: new（）に自動的に接続できるとしたらどうでしょうか。 それはきちんとしているでしょうが、残念ながらそれが100％可能であるかどうかも完全にはわかりません。

@alexcrichton必要なインポートを含む.wasmだけでなく、独自のJSを

そうすれば、純粋なwasmユーザーは独自のインポートを提供するだけですが、少なくともWeb AssemblyのすべてのWebユーザーは、面倒なことなく正しいJS対応物を使用してインスタンス化できます。

@jonhereはdebuginfo（ -g ）でコンパイルします。少なくともスタックトレースにもっと多くの関数を表示するのに役立つと思いますが、デバッグの話は素晴らしいものではないことに同意します。

@RReverserは当初、新しいターゲットを可能な限りむき出しにすることを目的としていました（余分なjsの綿毛はありません）が、js接着剤を放出する時点で、何をするかについてより柔軟に対応できるようになると思います。それを実装する方法。 私はその道をあまりにも早く下るのを警戒しています！

wasm32-unknown-unknownは、stdlibをすぐにサポートしないことを意味する場合でも、可能な限り必要最低限​​で自立した状態を維持することをお勧めします。 人々がカーネル開発に使用するターゲットと同様に、そのようなターゲットを持つことは重要です。 （ただし、その場合は、ユーザーが独自のtarget.jsonを作成できるようにするだけで十分だと思います。）

JS接着剤の放出を開始する場合、それはおそらく別のターゲットの一部であるはずです。 wasm32-unknown-web 、または何か。 そのターゲットは、stdlibを（移植性lintを介して）Webプラットフォームが提供するものだけにサブセット化し、emscriptenのようなエミュレーションを行わない可能性があります。 ここでは、JS接着剤を可能な限り最小限に抑え、インポートなしでWebプラットフォームに直接アクセスできる場合（いつ？）にJS接着剤を削除できるようにすることをお勧めします。

「システムアロケータ」のような概念は、ここの水をいくらか濁らせますが、Webプラットフォームはおそらくそれを提供することはないので、 dlmalloc-rsのような静的にリンクされたものを非#[no_std]デフォルトアロケータにしますwasm32-unknown-unknown #[no_std]使用は合理的かもしれません。

箱から出してstdlibをサポートしないことを意味する場合でも、wasm32-unknown-unknownを可能な限り必要最低限​​で自立したままにしておくことをお勧めします。

stdlibを気にしないユーザーの違いは何ですか？ 現在、「ベアボーン」アプローチでは、Rustコードでpanic!を使用してエラーが発生します。暗黙的なインポートでは、エラーが発生しますが、JSの対応物が欠落しているためです。 同時に、Webユーザーの場合、JS接着剤をインポートするとすぐに機能します。 私はそれを双方にとって有利だと考えています。

アイデアは、原料の束を取り除くためになくても、任意の暗黙の輸入を持っていないコードをサポートすることです。 移植性のlintおよび/またはstdlibがない場合、これは完全に実行可能であり、重要なユースケースです。

ため息を

そのような統合はまったく存在すべきではなく、どういうわけか必須ではないはずだと誰もが主張しているとは思いません。 多分それは2つのターゲットを持つことを意味します。

@RReverser私はそれをまったく主張していません！ そのサポートは存在するwasm32-unknown-unknown行われた作業に基づいて確実に構築されます。 -unknownトリプルは、プラットフォーム固有の接着剤（つまり、web / node.js）を配置するのに適した場所ではありません。 wasm32-unknown-nodeおよび/またはwasm32-unknown-webは、そのためのより良い場所です。

バイクシェディの領域では、そのようなターゲットにwasm32-rust-node / wasm32-rust-webに投票します。 😄

stdwebが未知のターゲットのサポートを獲得したので、libstdの内部からstdwebからコンポーネントを使用するという具体的な提案について話すことができると思います。 irloでスレッドを開きました。

しかし、実際にはMath。*プラットフォーム固有ですか？ ES規格で定義されていると思いました。 特定のターゲットに固有でない限り、未知のターゲットには問題ありませんか？

@jontro Wasm！= JavaScript。

WasmはJavaScriptなしで動作するように特別に設計されているため、wasmにコンパイルする場合、JavaScript APIが存在すると想定することはできません（存在しない可能性があるためです）。

したがって、 wasm32-unknown-unknownでJavaScript API（ Mathを含む）を使用することはできませんが、 wasm32-unknown-nodeとwasm32-unknown-web JavaScriptAPIを使用することはできます。

@Pauanが言ったことは、webassemblyのWebサイトにも記載されてい

非Web環境にはJavaScriptVM（node.jsなど）が含まれる場合がありますが、 WebAssemblyは、JavaScriptVMが存在しなくても実行できるように設計されています。

したがって、jsにまったく依存しないターゲットを維持する必要があります。 wasm32-unknown-unknownはぴったりのようです。

（それを最小限に抑えないことなどについて議論しないでください。）

そのため、JavaScriptAPIを使用することはできません

現時点では直接使用していないので、ターゲットの数が増えるのを止めることはできません。 WebAssemblyは、インポートとエクスポートのAPIを定義します。 rust関数の引数（ bool 、 *const f64 ）を作成すると、コンパイラはそれらをWebAssemblies4データ型に変換します。 javascriptエンジンでも同様のことが起こります。 （bool（など）のrustsendはNumberになります。逆に、javascript Booleanを送信してboolにすることができます。）

@jonhereWebAssemblyは常にJavaScript環境で実行されているわけではあり完全に分離され、無関係になるように、特別かつ意図的に設計されています。

CでWebAssemblyを実行したり、JVMでWebAssemblyを実行したり、洗濯機でWebAssemblyを実行したりするための実装はすでにあり

明らかに、これらの実装にはJavaScriptAPIがありません。 JavaScript APIは実行時にまったく存在しないため、Rustが何を実行しても、JavaScriptAPIを使用することはできません。 実行時にパニックが発生します（せいぜい）。

@Pauanしかし、反対側のAPIバインディングがJS、C、Java、またはその他のものによって提供されているかどうかは実際には問題ではありません。 重要なのは、それらがRust側にインポートされることです（とにかくLLVMで必要なものがすでにあるため）。これらの実装はすべて、WASMから相互運用を奪うことなく、反対側で独自のネイティブバインディングを自由に提供できます。

繰り返しますが、ネイティブwasmはMath.*提供しないため、 -unknownターゲットはそれを使用しないでください。 これは、RustとCの両方で、他の-unknownターゲットとの連携方法です。

自分でインポートを追加して、JavascriptやCなどのMath.*ような関数を提供したい場合は、それで問題ありません。誰もあなたを止めません。 しかし、これらのインポートを自動的に追加するコンパイラーは、初心者ではありません。

編集：いくつかの例外は、Cコンパイラの「組み込み」関数が-unknownターゲットの自立モードであっても、ソースに記述せずにmemcpyなどへの呼び出しを生成することです。 ただし、これはオプトアウトでき（GCCでは-fno-builtin ）、これらの関数はとにかくC内から提供できます。

はい、それが期待するJavaScript APIであってはなりませんが、代わりにstdは、関連するすべてのAPI（Instant、stdin、stdoutなど）に必要なシンボルを定義する必要があります。 これらのシンボルは、WebAssemblyを実行しているものなら何でも提供でき、これらのシンボルを自動的に提供するJavaScriptバインディングは、コンパイラーによって自動生成されます。

@RReverser複数のターゲットによって提供できるAPIがある場合、APIは条件付きコンパイルを使用して、複数のターゲットで機能するようにすることができます。

ただし、そのような状況でも、 wasm32-unknown-unknownターゲットにはプラットフォーム固有のコードが含まれていないと想定されているため、 wasm32-unknown-unknownターゲットでは機能しません。

wasm32-unknown-unknownターゲットを使用してコードをコンパイルすると、「このコードをすべてのWebAssembly実装で機能させたい」と言っています。 したがって、使用できるコードはネイティブのwasmコードのみであり、プラットフォーム固有のコードはありません。

もちろん、あなたのような、別のターゲットを使用する場合はwasm32-unknown-webあなたの指定した意図が異なっているので、あなたは、（そのようなJavaScriptのバインディングなど）非wasmバインディングを使用することができ、。 その場合、もちろんコンパイラは自動的にJavaScript APIを使用する必要があるため、すべてがスムーズかつシームレスに機能します。

@CryZeそれはおそらく良い考えです！ それでもwasm32-unknown-unknownには適用されませんが、他のwasm32-*ターゲットには役立ちます。

大きく壊れた性感染症の利点は何ですか？ stdは、通信する適切なインターフェイスを定義する必要があります。 実際に使用するこのインターフェースのサブセットのみをコンパイルする必要があるため、実行時にランダムなパニックが発生することなく、stdを使用することのすべての利点があります。 本当に「OS」と対話したくないのなら、そもそもなぜstdを使用するのでしょうか。 それがコアの目的です。

ターゲットにはプラットフォーム固有のコードが含まれていないはずです

問題は、例で見たように、プラットフォーム固有のコードではないことです。このようなバインディングは、一部の基本的な数学演算でも必要です。 そして、 @ CryZeが言うように、stdに対してコンパイルする人のためにstdを実装することはそう遠くありません。

次に、wasm以外のバインディング（JavaScriptバインディングなど）を使用できます

私が言ったように、それらはJSバインディングである必要はなく、Javaバインディング、Cバインディング、またはその他のものである可能性があります。したがって、 -webサフィックスは、Webまたは一般的なプラットフォームではないため意味がありません。 -そもそも特定のバインディング。 これらは、RustWASMが依存する基本的な「カーネル機能」にすぎません。

stdは、代わりに、関連するすべてのAPIに必要なシンボルを定義する必要があります

これは良いアイデアのIMOです。

考えてみると、この「カーネルインターフェイス」はやや一般的であると思われるため、あらゆる種類のOS /ランタイムに簡単に接続するための柔軟な方法として、Rustがこれをwasmターゲットの外に置くことは理にかなっています。

std-on-wasmに必要な明確に定義された（安定した！）インポートのセットは素晴らしいアイデアであり、 -web / -nodeターゲットの理想的な基盤を形成します。

純粋にオプトインの場合は、 -unknownターゲットで使用することもできます。 繰り返しになりますが、 -unknownをターゲットにすると、プログラムで宣言されているものを除いて、インポートがゼロになるはずです。 このシナリオでは、ずっと使用してのようになるliballocとlibcollectionsから#[no_std]あなたは何も開始し、意図的にそこから作品を追加します- 。

-unknownから始めますが、インポートをゼロにするためにさらに多くのものを取り除いておく必要はありません。

大きく壊れた性感染症の利点は何ですか？

@CryZeサブセット化された標準には多くの利点があります。そのため、 https：//github.com/rust-lang/rfcs/pull/1868がマージされました。 単に何かをサポートしていないターゲットは、コアに完全にドロップすることなく、コンパイル時にドロップすることができます。

ターゲットにはプラットフォーム固有のコードが含まれていないはずです

問題は、例で見たように、プラットフォーム固有のコードではないことです。このようなバインディングは、一部の基本的な数学演算でも必要です。

@RReverser -unknownスタイルのターゲットではこれは完全に正常です。 多くの組み込みシステムには同じ「基本的な数学演算」がなく、WebAssembly（現在）も同様であるため、これは-unknownターゲットで表す必要が

そして、 @ CryZeが言うように、stdに対してコンパイルする人のためにstdを実装することはそう遠くありません。

「基本的な数学演算」から「すべての標準」に移行するのは非常に遠いです。その距離の多くは、Web上でのエミュレーションを必要とします。 正直なところ、 -webターゲットでさえすべてをサポートする必要はなく、Webプラットフォームがサポートするstdのサブセットのみをサポートする必要があります。

より建設的にするために、私はターゲットが次のように見えることを想像します：

-unknown ：デフォルトではゼロインポート。 WebAssemblyにネイティブに欠けている数学演算をサポートしていません。また、WebAssemblyの外部からのサポートを必要とするstdの機能をサポートしていません。 プログラムが適切なインポートを宣言すると（アロケータの定義と同様）、より多くの操作の使用を開始できます。

-web ：Webプラットフォームで直接サポートされているものにのみインポートします。 したがって、標準出力の多くをサポートすることはできません-標準出力はconsole.logに直接送られ、 File::open 、 TcpStream 、 std::processはなく、 std::threadはWebワーカーに直接対応します（そのようなサブセットが存在するかどうかを言うには十分な知識がありません）。 それ以外のもの（WebSocketなど）は、他のクレートによって提供される必要があります。

-node ：Nodeが実際にこれらのAPIを提供しているため、通常のデスクトップターゲットに非常によく似ています。 （ただし、Nodeはイベントループベースであるため、実際にはこれらのAPIをあまり使用したくない場合があります。）

Webプラットフォーム上のすべての標準をエミュレートする-emscriptenようなものは確かに便利です。 ただし、たとえばWebプラットフォームに直接書き込みたいときに、エミュレーションレイヤーを削除する必要がないように、別のターゲットのままにする必要があります。 Emscripten自体とは別にこのようなものを提供したい場合は、それを呼び出すことができます... wasm32-rust-stdweb ？

@rpjohnst webとnodeを分離することは非常に珍しいことです。これは、JSライブラリが変更なしでさまざまな環境で普遍的に機能することが期待されるためです（これが、Node.jsライブラリのほとんどが独自のブラウザ化された対応物を持っている理由です、すべての機能をサポートしていなくても、環境間で同じコードを移植することを避けるために、バンドルしてすぐに使用できます）。

いずれにせよ、RustはこれらのJS実装の詳細を知る必要はなく、上記の一般的なカーネル関数を参照するだけなので、Rust側に-webまたは-nodeまたはその他のプレフィックスを含めることはできません。実際にはこれらの実装を提供しないため、意味がありません。生成されたWebAssemblyコードを実行しているものによって提供される特定のCのようなバインディングを期待してください。

したがって、ここで全員が同じページにいることを確認するために、WebAssemblyの仕様ではプラットフォームの詳細は定義されていません。 プラットフォームの詳細は上に階層化されることが期待されます。 これは特に、wasmをWebコンテキストの外部で使用できるようにするためです。実際、これは全体として重要なユースケースであるだけでなく、本番環境のRustユーザーにとっても重要なユースケースです。Etheriumはスクリプト言語としてwasmを使用することを計画しています。 、 例えば。

そのため、 unknownターゲットがhttps://webassembly.github.io/spec/のみを実装し、他には何も実装しないことを強く望んでいます。 Webプラットフォーム統合を処理するためのwebターゲットを定義する必要があります。

私たちが主張しているのは、-webがあってはならないということです。 たぶん、-stdまたは適切なstd実装を備えたものであり、stdがスタブアウトされたターゲットに実際に正当な理由がある場合は、これでまったく問題ありません。 しかし、人々がスタブアウトされた標準を持つターゲットを主張しているという事実は、人々が本当に避けようとしているコアに実際にはかなり何か問題があるように見えます。

@CryZeの言葉をここで説明しているすべてのバインディングは、Web、Node.js、またはその他のホストに固有のものではありません。 RustがWebプラットフォームの統合を行うことは期待も望んでもありません。これは、カスタムクレートとnpmパッケージで行うことができます。 必要なこれらのバインディングは非常に一般的であり、Rustが任意のプラットフォームでstdクレートを適切に機能させるために必要ですが、反対側の実際の実装は、WebAssemblyをホストするすべてのコード、VM、またはプラットフォームによって提供できます。 。

これは、ポータビリティリントと完全に直交しており、このような一般的な「カーネル」バインディングと組み合わせて使用​​される場合と使用されない場合があります。

しかし、人々がスタブアウトされた標準を持つターゲットを主張しているという事実は、人々が本当に避けようとしているコアに実際にはかなり何か問題があるように見えます。

コアに問題があり、誰もそれをサポートしていません。

しかし、私はポータビリティリントのアイデアがalloc cfgを提供し、 stdとallocメインクレートから切り替え可能にすることで、 libcoreとliballoc廃止することもできます。

webとnodeを分離することは非常に珍しいことです。これは、JSライブラリが変更なしでさまざまな環境で普遍的に機能することが期待されるためです（これが、Node.jsライブラリのほとんどが独自のブラウザ化された対応物を持っている理由です。すべての機能をサポートしていない場合は、環境間で同じコードを移植することを避けるために、バンドルしてそのまま使用します）。

@RReverser問題の事実は、Nodeは、Webがエミュレーションなしではサポートしない、またはできない多くの機能をサポートしているということです。 これは、その機能を除外するサブセット化されたstdを持つ-webターゲットの場所があることを意味します（たとえば、 File::open 、 TcpStream 、 std::process ）。そのためのインポートを生成しません。

人々はスタブアウトされた標準でターゲットを主張しています

@CryZe明確にするために、私はサブセット化された標準を主張しています。 このように、ブラウザでホストされるwasmでRustを使用するには3つの層があります。

• -unknown ：すべてのインポートを制御し、ホストからのサポートを必要とするstdの部分を使用せずに実行します（インポートを明示的に追加して自分で接着する場合を除く）。
• -web ：コンパイラは、stdが必要とする非Web固有のもののインポートとグルーコードを生成します（ @RReverserがhttps://github.com/rust-lang/rust/issues/44006#issuecomment-で説明しているように） 353447483）。ただし、Webプラットフォームで提供できるもの（例： Math.* ）のみ。
• -emscripten / -stdweb ：コンパイラは、stdが必要とするすべてのインポート（完全な「汎用カーネルバインディング」）を生成し、Javascript側で必要なグルーコードとエミュレーションを提供します。 エミュレーションはRustチームによって維持される必要はなく、プラットフォームの一部と見なされます。

-nodeターゲットは同じ原則に従います。つまり、ノードが提供できるstdが使用するすべてのインポートとグルーコードを生成します。 これがstdのすべてになると思うので、Nodeの-emscriptenようなターゲットは必要ありませんか？

これは、その機能（File :: open、TcpStream、std :: processなど）を除外するサブセット化されたstdを持つ-webターゲットの場所があり、したがってそのインポートを生成しないことを意味します。

それほど必要ではありません。 TcpStreamsがWebSocketプロキシを使用してブラウザーに実装されている場合があります（これは実際に機能し、ブラウザーのx86エミュレーターなどで使用されます）。File:: openはFileAPIを使用して実装するか、ローカルストレージを指すなどです。 動的言語の反対側で何を期待し、これらのAPIをどのように実装するかを決定するのは、Rustの仕事ではありません。これは、コンパイルされたWASMの利用者次第です。

-web

ただし、Webプラットフォームで提供できるもの（Math。*など）のみ

-emscripten / -stdweb

以前のコメントからのポイントを繰り返すと、これらがWebプラットフォームに固有のものではなく、同じ数学バインディングがJVMやCなどの他のコンシューマーによって普遍的に提供できる場合、なぜこれが-webまたは同様のターゲットに分離されるのでしょうか。

TcpStreamsがWebSocketプロキシを使用してブラウザーに実装されている場合があります（これは実際に機能し、ブラウザーのx86エミュレーターなどで使用されます）。File:: openはFileAPIを使用して実装するか、ローカルストレージを指すなどです。

日付などを取得するためのAPIには、現時点でJavaScriptが必要であり、それらを実装する方法は1つしかありません。 ファイルシステムの選択を自由にしたい場合は、それをプログラムに入れてください。 なぜここで抽象化レイヤーを錆びさせる必要があるのですか？ ライブラリコードは、読み取り/書き込み特性を暗示するすべてのもので機能する必要があり、カーソルにすることができます。

以前のコメントからのポイントを繰り返すと、これらがWebプラットフォームに固有のものではなく、同じ数学バインディングがJVMやCなどの他のコンシューマーによって普遍的に提供できる場合、なぜこれが-webまたは同様のターゲットに分離されるのでしょうか。

また、Windows、Mac、Linuxのターゲットを分離することもできます。 ワインがあり、人々はどこでもWindows APIを使用できますが、それでも誰もがネイティブにコンパイルしたいと思っています。 その理由は、すべてが特定のターゲットに合わせて調整されるためです。

ワインがあり、人々はどこでもWindows APIを使用できますが、それでも誰もがネイティブにコンパイルしたいと思っています。 その理由は、すべてが特定のターゲットに合わせて調整されるためです。

この理由は、単にあなたの消費者がワインを持っていると期待することができないということです。 より良い例は、Rustが-linux-gnu 1回だけコンパイルするLinux GNUターゲットであり、これはほとんどすべての人に不満なしで機能します。

WebAssemblyを使用することをお勧めします- std予想されるバインディングをリストし（私が気にしていることですが、それらのほとんどは通常のPOSIX関数宣言でもかまいません）、Rustコンパイラーでも実装の詳細を知る負担をかけませんRust開発者でもありません。

JavaScriptライブラリは、ここ数年、厳密にユニバーサル（またはいわゆる「同形」）に向かっています。WebAssemblyターゲットが-web 、 -nodeを分離することは、大きな一歩となるでしょう。そもそもユニバーサルになるように意図的に設計された場合の

なぜここで抽象化レイヤーを錆びさせる必要があるのですか？

@ est31どうして？ 異なるターゲットで機能する各クレートの複製を作成しますか、それともstd APIを使用して任意の環境で機能する単一のクレートを使用しますか（現在のRustコードの大部分と同じように）？ たとえば、WebAssemblyコードを消費しているものの反対側にMath.fmulがどのように実装されているかを知ることで、何が得られますか？

TcpStreamsがWebSocketプロキシを使用してブラウザーに実装されている場合があります（これは実際に機能し、ブラウザーのx86エミュレーターなどで使用されます）。File:: openはFileAPIを使用して実装するか、ローカルストレージを指すなどです。 動的言語の反対側で何を期待し、これらのAPIをどのように実装するかを決定するのは、Rustの仕事ではありません。これは、コンパイルされたWASMの利用者次第です。

これは意味がありません。 WebSocketプロキシを介したTcpStreamエミュレーションを含む、またはサポートするターゲットを提供することに反対する人は誰もいません。 私たちはすでにそれを持っています、そしてそれは素晴らしいです！ さらに、私が欲しいのは、WebプラットフォームがTCPを提供しないため、 TcpStream提供しない-webターゲットです。

異なるターゲットで機能する各クレートの複製を作成しますか、それともstd APIを使用して任意の環境で機能する単一のクレートを使用しますか？

あなたは混乱しているようです。 すでに-emscriptenを介してクレートをクロスプラットフォーム化しており、標準のどの部分も使用しないクレートについては、引き続き-webと-nodeで使用します。エミュレーションが必要です。 これらのターゲットのポイントは、エコシステムを分割することではなく、エミュレーションなしで接着剤の薄層のみを必要とするwasmモジュールを生成する方法を人々に提供することです。 たとえば、 x86_64-pc-windows-msvcとx86_64-unknown-linux-gnu間で分割されたエコシステムの欠如を参照してください。

異なるターゲットで機能する各クレートの複製を作成しますか、それともstd APIのみを使用し、任意の環境で機能する単一のクレートを使用しますか（現在のRustコードの大部分と同様）。

私は絶対に重複を嫌います。 ただし、ライブラリが読み取り/シーク/書き込みトレイトimplで機能する機能を公開し、パスを取得してそれ自体をシリアル化するだけではない場合、これは発生しません。

JavaScriptライブラリは、ここ数年、厳密にユニバーサル（またはいわゆる「同形」）に移行してきました。WebAssemblyターゲットが-web、-node、またはその他のサブターゲットを分離することは、大きな一歩となるでしょう。そもそも普遍的であるように意図的に設計されています。

繰り返しになりますが、C / JVMベースのターゲットはjavascriptとまったく接触しない可能性があり、一部のユースケースは確かに接触しません。 JsレイヤーにAPIを配置しないでください！ 統合については、それは素晴らしいことです。ほとんどのコードは-nodeターゲットと-webターゲットの両方で機能すると思いますが、ブラウザー間には違いがあり、コンパイル時に区別できるはずです。今日、 i586-pc-windows-gnu i686-pc-windows-gnuターゲットと

私たちはすでにそれを持っています、そしてそれは素晴らしいです！ さらに、WebプラットフォームがTCPを提供しないため、TcpStreamを提供しない-webターゲットが必要です。

しかし、ブラウザ間には違いがあり、それらについてはコンパイル時に区別できるはずです

繰り返しますが、主な質問：なぜあなたはそれが欲しいのですか？ それはあなたに何を与えますか？ プラットフォームでバインディングが欠落しているWebAssemblyをインポートしようとすると、サポートされていないものに対してまったく同じエラーが発生します。ただし、既に使用済みライブラリに依存している場合は、サイドでスタブすることを選択できます。 このようにして、サポートされているすべてのプラットフォームに同じWebAssemblyライブラリを配布することが可能になり、コンシューマーはRustコードを再コンパイルせずに、プラットフォームのバインディングを使用してライブラリをインポートするだけで済みます。

すでに-emscriptenを介してクロスプラットフォームのクレートを作成しています。

-emscriptenは非常に異なり、すべてに内部JSバインディングを提供します。 ここでは、JSだけでなくWebAssemblyのより普遍的なターゲットについて話していると思いましたか？

繰り返しになりますが、C / JVMベースのターゲットはjavascriptとまったく接触しない可能性があり、一部のユースケースは確かに接触しません。

もちろん、それが私たちが実現したい目標です。 提案されたバインディングはいずれもJS固有のものではなく、上記で何度も述べたように、いずれもそうである必要はありません。これらはすべて、あらゆるプラットフォームに共通する通常の「カーネル機能」です。

これはすべて、WebAssemblyが同じWebAssemblyモジュールをJava / Web / C / ...に貼り付けるだけの移植性があるかどうか、または常に再コンパイルする必要があるかどうかにかかっているようです。 移植性が高い場合は、モジュールが通信する1つの定義済みカーネルインターフェイスが必要です。 そうでない場合は、複数の個別のターゲットを選択する必要がありますが、その場合、wasmモジュールが移植可能であることを完全に見逃します。

これはすべて、WebAssemblyが同じWebAssemblyモジュールをJava / Web / C / ...に貼り付けるだけの移植性があるかどうか、または常に再コンパイルする必要があるかどうかにかかっているようです。

うん、あなたはこのスレッドで2つのキャンプをかなりうまく要約したと思います。 私はポータブルなものにいます-結局のところ、特定のオペレーティングシステムや仮想マシンなどから抽象化し、それらのいずれかに実行可能な単一のバイナリ形式をすぐに提供することがWebAssemblyの主要な目標の1つでした。 この抽象化を削除してターゲットごとに再コンパイルする必要はないようで、WASMは一部のCコードやLLVMIRよりもほとんど役に立ちません。

@CryZeの移植性は、少なくとも私にとっては、異なる埋め込み間ではなく、オペレーティングシステムとハードウェア間で移植可能であることです。 埋め込みはめったに変更されません。変更された場合は、再コンパイルできます。 つまり、埋め込み間で移植可能であることの重要性については私と意見が合わないかもしれませんが、いずれにせよ「完全に見逃す」というのはかなり誇張されています。

プラットフォームでバインディングが欠落しているWebAssemblyをインポートしようとすると、サポートされていないものに対してまったく同じエラーが発生します。ただし、既に使用済みライブラリに依存している場合は、サイドでスタブすることを選択できます。

@RReverser

選択的に有効にするだけで、 -unknownターゲットからその機能を取得できます。 違いは、リーフクレートでオプトインする必要があることです。

ただブラウザに投げ込んで動作させることができるwasmmodule + js接着剤をコンパイルする方法があるはずです。 したがって、 -webと-emscripten 。 そうすれば、Webアプリケーションを構築するために余分な作業を行う必要はありません。

これはすべて、WebAssemblyが同じWebAssemblyモジュールをJava / Web / C / ...に貼り付けるだけの移植性があるかどうか、または常に再コンパイルする必要があるかどうかにかかっているようです。 移植性が高い場合は、モジュールが通信する1つの定義済みカーネルインターフェイスが必要です。 そうでない場合は、複数の個別のターゲットを選択する必要がありますが、その場合、wasmモジュールが移植可能であることを完全に見逃します。

@CryZe

これは私の議論の不正確な説明です。 私たちは両方を持つことができます！ 私たちは、STDが必要とする標準インタフェースを定義する必要があります。 また、特定の埋め込みをターゲットにして、それらのグルーコードを生成できるようにする必要が

おそらく、追加のターゲットまたはフラグが役立つでしょう。これは、すべてのインポートを生成しますが、グルーコードを生成しないという点で、 -emscripten / -stdweb動作を取得する方法です。

ああ、それなら私たちはお互いを超えて話していたに違いありません、なぜなら私はそれに完全に同意するからです。 rustには特定のターゲットがないすべての種類のランダムな埋め込みをサポートするには、標準のインターフェースが必要だと思いますが、特定のターゲットには、jsのようなより具体的なバインディングとAPIが確実に含まれる可能性があります。 マクロと多分いくつかのDOMAPI。

だから....私たちは皆、jsマクロに同意しますか？ 言語にRFCを追加するためのRFCを書いています。 ここにリンクします。

これらを確実に存在させたいのですが、カスタムマクロやDOM APIなどが、他のユーザーランドコード、特に統合固有のコードと同じように、カスタムクレートやnpmパッケージに存在できない理由がわかりません。

彼らは、 #[cfg]とコンパイラのサポートを整理するためのターゲットとともに、できるし、そうすべきです。

したがって、これらの追加のターゲットは便利ですが、現在のwasm32-unknown-unknownターゲットの場合は、次の関数ポインターをエクスポートする必要があります。

• stdoutへの書き込み
• stderrへの書き込み
• 終了コードの設定
• stdinから読んでいますか？

WebAssemblyがどのようにホストされているかに関係なく、ホストはこれらの関数ポインターを設定するか、未設定のままにするかを選択できます。それらが設定されていない場合、動作は今日のようになります。それらが設定されている場合、libstdはそれらを呼び出して各ケースを処理します。

これにより、現在のブロッカーが解決されます。つまり、ブラウザーでwasmテストを実行できますが、それらが成功したか失敗したかはわかりません...（libstdは現在、stdout、stderr、および終了コードを破棄します）。

@RReverserこのようなマクロには複数の異なる実装があります。 1つの実装を使用する場合は、事後にその実装のツールを使用する必要があります。 コンパイラーにある場合は、最小限の標準として機能します。 また、stdでも使用できます。 stdは他のクレートに依存できないため、このようなマクロを持つことは、調整されたstdAPIを備えたターゲットの要件になります。

完全にダイナミックなターゲットのアイデアについては、持っていると便利だと今では確信しています。 wasm32-unknown-unknownはそのように機能することができます。 私はRFCのアイデアを使い果たしていません...

事後にその実装のツールを使用する必要があります

あなたはおそらく正しいです、jsのために！ マクロそれは本質的に独自のリンクステップを必要とするので理にかなっています（少なくともリリースビルドの場合、デバッグビルドの場合、キャッシュインデックスとして文字列のポインタを使用してJS側にnew Functionを動的に作成できます。その後、単一のインポートを行うことができますマクロを機能させるためのFFIバインディング）。

ただし、DOMなどの場合は、独自のクレート/パッケージに入れるのが理にかなっていると思います。コンパイラやstdの内部から多くを必要とせず、 js!上に構築できます。

ただし、DOMなどの場合は、独自のクレート/パッケージに入れるのが理にかなっていると思います。コンパイラやstdの内部をあまり必要とせず、jsの上に構築できます。

間違いなく、これは木枠に属しています。 stdには、他のプラットフォームでも提供される機能以外の追加機能はありません。

@Diggseyは彼らのアイデアを実装するPRを行いました。 購読しているすべての人をccする： https ：

これが開かれてからかなりの進歩がありました。マスターのEmscriptenバックエンドから完全に切り離され、wasm32-unknown-unknownがこれらの要素の多くを取得し始めたため、これを閉じます。

一般的にはEmscriptenマスターをフォローしますが、これはこの時点ではrust-lang / rustではなく、Emscriptenのバグであることがほとんどなので、終了します。