Rust part10

**デフォルトの名無しさん** · 2021/04/02(金) 21:38:04.11

Mozilla発のRust言語のスレ

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

前スレ
Rust part9
https://mevius.5ch.net/test/read.cgi/tech/1598112455/

**デフォルトの名無しさん** · 2021/05/23(日) 16:18:03.34

>>735
static変数とglobal変数はスコープが違うだろ
global変数が悪とされるのは、そのスコープの広さだからね

いつどこで誰が変更するのか、また参照するのか、スコープが広ければ広いほど把握が困難になる
把握が困難になればなるほど、それだけバグを生む温床になる

**デフォルトの名無しさん** · 2021/05/23(日) 18:34:32.71

io周りは極論すればどう管理してもグローバルだからな。
プロジェクト毎に規約設ける以外にまともに管理する方法なんてない。

**デフォルトの名無しさん** · 2021/05/23(日) 20:09:32.32

>>735
そういやロガーの設定ってどこに保存されてるの？
debug!() 呼ぶたびにMutexロックしてるのかな？

**デフォルトの名無しさん** · 2021/05/24(月) 12:11:21.84

>>736
クラスの中に入れても、グローバル変数であることは避けられないし
どんな言語においてもグローバル変数は必要。

**デフォルトの名無しさん** · 2021/05/24(月) 12:28:02.03

「:?」ってなんなんですか？
https://tourofrust.com/08_ja.html

**デフォルトの名無しさん** · 2021/05/24(月) 12:49:55.25

>>741
デバッグ用のフォーマットで出力するという意味
詳しくは以下参照
https://doc.rust-lang.org/std/fmt/

**デフォルトの名無しさん** · 2021/05/24(月) 13:24:07.35

>>740
そんなことはないだろう。
確かにグローバルでも大して変わらんてものはあるけど、
loggerを引数で渡していくっていうような実装方法もある。

**デフォルトの名無しさん** · 2021/05/24(月) 13:33:20.21

>>739
logクレートのstatic mut変数だね
ロックするのは初期化とレベル設定時だけ
出力時にロックするかどうかは実装次第

**デフォルトの名無しさん** · 2021/05/24(月) 15:43:10.46

>>740
そのクラスの存在そのものがグローバル変数(相当)だという話？
それともそのクラスもしくはそのインスタンスをグローバル変数に入れて使うということ？
後者の意味ならば必要な範囲で引数として持ち歩けばグローバル変数を普通は使わないですよね。

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/24(月) 16:59:24.57

大事なのは抽象化がきちんとしているかどうか。
各部品が妥当な意味に分離されているかどうか。

グローバル変数がよくないのは色んなパーツから横断的に使われる可能性があって
部品が不必要に密結合していることの表れだからであって、
そのグローバル変数のアクセス範囲が妥当な範囲に制御されているなら問題じゃないよ。

過剰な密結合を解消せずにグローバル変数を引数に置き換えてたら
影響範囲が見えにくくなってもっと悪くなることだってありうる。

まあどういう場合なら妥当なのかってのは色々と意見はあると思うけど。

**デフォルトの名無しさん** · 2021/05/24(月) 17:17:23.03

$_POSTはセーフ

**デフォルトの名無しさん** · 2021/05/24(月) 17:21:32.94

>>746
まずは長くて区別しやすい名前に変えるのがスタートかね。

**デフォルトの名無しさん** · 2021/05/24(月) 17:31:54.98

>>742
ありがとう！なんか独特なのね

**デフォルトの名無しさん** · 2021/05/24(月) 23:12:37.25

関数型言語やったことないけど、Rustいけるかな
JavaとC++はそこそこ経験あり

**デフォルトの名無しさん** · 2021/05/24(月) 23:17:37.88

Java 8とかC++ 14以降くらいなら結構似たような機能も入ってるし
そこまで大変じゃない気がする

**デフォルトの名無しさん** · 2021/05/24(月) 23:36:00.17

c++はともかく、cくらいはやっぱ理解してた方が早道な気はする。

**デフォルトの名無しさん** · 2021/05/25(火) 01:36:21.07

以下のような関数を作ったんですがmatchが多くてどうしようか考えていました

fn foo(x: Option<u32>, y: Option<&str>) { //実際はOptionが5個とか
let x = match x {
Some(x) => x,
None => return,
};
let y = match y {
Some(y) => y,
None => return,
};
println!("{} {}", x, y);
}

考えついたのが、次のようにする方法なのですが、
fn foo(x: Option<u32>, y: Option<&str>) -> Option<()> {
let x = x?;
let y = y?;
println!("{} {}", x, y);
Some(())
}

記載の省略のためだけに返値の型をOption<()>にして最後にSome(())つけるのがすごく気持ち悪いんですが、
返値なしのままどうにかする方法はないでしょうか

**デフォルトの名無しさん** · 2021/05/25(火) 02:11:48.11

if_chain使って
if_chain!{
if let Some(x) = x;
...
then { println!("{}", x); } }

**デフォルトの名無しさん** · 2021/05/25(火) 02:16:51.35

>>753
fooの型変えられないなら、戻り値Optionはクロージャないしローカル関数に留めるといいと思う
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=aa2bc019e7329f1b6bece2597b59ee8a

**デフォルトの名無しさん** · 2021/05/25(火) 03:00:10.05

Ok(())はよく使うがSome(())はないな

普通にif-letでパターンマッチするのでよくない？
if let (Some(x), Some(y)) = (x, y) {
println!("{} {}", x, y);
}

**デフォルトの名無しさん** · 2021/05/25(火) 05:18:39.47

loggerを引数で渡すためには
ロギングを行うクラスFooがどこかしら（コンストラクタか個々のメソッドで）loggerを受け取る引数を持たねばならない
これ、ロギングみたいな裏方の仕事がFooのインターフェース仕様に影響しているということで、
抽象度が下がってるやんけ；；；

引き換えに得られるメリットは、Fooのインスタンスごとにloggerを切り替えられるというおおよそ現実的にありがたみが無い機能だけ

**デフォルトの名無しさん** · 2021/05/25(火) 06:08:48.35

>>756
それをmachでやるのがよくない？

**デフォルトの名無しさん** · 2021/05/25(火) 06:23:40.79

つか機能の分離と記述の分離はトレードオフがある
1+1=2の形式的証明がどんだけの糞みたいな分量のに成り得るかを見たらﾜｶﾙ
どっかの抽象度をつきつめれば別のところにしわ寄せが逝く
それで良いｼﾞｬﾏｲｶ人間の言語だもの、

**デフォルトの名無しさん** · 2021/05/25(火) 09:01:56.56

皆様ありがとうございます
どうもSomeをある程度書くのは避けられない感じですね

**デフォルトの名無しさん** · 2021/05/25(火) 10:09:28.07

まさかstatic変数使ってるなんて、logクレートには失望したわ

**デフォルトの名無しさん** · 2021/05/25(火) 10:33:41.89

>>757
ログを裏方と考えるのも偏ってるし、ログ切り替えはデバッグ目的で普通にあるわ。
別にグローバルにするという選択が間違いとも思わんがこういう決めつけ野郎は邪魔だな。

**デフォルトの名無しさん** · 2021/05/25(火) 10:59:01.14

サーバ側だとログを取るのが基本だし取り方も変えたくなるからlogger渡しは結構やるな
CLIとかなら雑にstaticでいいけど

**デフォルトの名無しさん** · 2021/05/25(火) 13:12:03.88

>>761
stdも使えないじゃん

**デフォルトの名無しさん** · 2021/05/25(火) 18:48:30.58

>>764
なんで？

**デフォルトの名無しさん** · 2021/05/25(火) 19:25:41.69

>>765
https://github.com/rust-lang/rust/blob/a7890c7952bdc9445eb6c63dc671fa7a1ab0260d/library/std/src/io/stdio.rs#L553

**デフォルトの名無しさん** · 2021/05/25(火) 19:39:28.48

>>766
えー
これからは write() システムコールでプリントするわ

**デフォルトの名無しさん** · 2021/05/25(火) 21:02:03.28

stdが嫌ならcoreを使え

**デフォルトの名無しさん** · 2021/05/25(火) 22:59:34.15

>>762
近代的なログシステムならタグが使えるから
記録時に分っける理由がさらさらない
だいたい並列な事象を並列なまま記録したのでは時系列の解析ができないし、

そもそも>>762がいくら「ログは裏方じゃない」と叫んだところで基準が無い
アプリケーションロジックを汚してまでか？！という議論はいつまでもつきまとう

**デフォルトの名無しさん** · 2021/05/26(水) 00:00:47.75

別に仕事で使ったことないならそういえばいいと思うよ。悪いことしてるわけじゃないんだから。

**デフォルトの名無しさん** · 2021/05/26(水) 00:04:47.15

そういやLog4JでいうMDCみたいなやつはあるのかしら？

**デフォルトの名無しさん** · 2021/05/26(水) 00:07:56.89

お前らslog

>>760
ただのzipやん。
ttps://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=01c2f30ff2a49dc57c917ec16947aadb

**デフォルトの名無しさん** · 2021/05/26(水) 08:19:13.92

まあloggingオブジェクトを複数作る仕事なんなら仕方が無いな

**デフォルトの名無しさん** · 2021/05/26(水) 08:29:19.07

slog見たけど、クソややこしいな

**デフォルトの名無しさん** · 2021/05/28(金) 09:51:25.19

シンタックスで判断しづらいもので性的分析するって、そのうち破綻しそうだな。

**デフォルトの名無しさん** · 2021/05/28(金) 09:54:11.42

エロい分析か

**デフォルトの名無しさん** · 2021/05/28(金) 10:45:17.68

やらC

**デフォルトの名無しさん** · 2021/05/29(土) 20:28:41.06

JPEG-XLのリファレンス実装作ってるチームがRustで再実装も始めてて驚いた
https://github.com/libjxl/jxl-rs

FirefoxにJPEG-XL対応を入れるかどうか議論するチケットで
今更大量のunsafeなC++コードを入れるのはちょっと……みたいな反応をされてた事と関係あるのかもしれない

**デフォルトの名無しさん** · 2021/05/30(日) 15:56:56.42

https://4e6.github.io/firefox-lang-stats/
https://www.openhub.net/p/firefox/analyses/latest/languages_summary
Firefox､かなりの割合でC++のコード入ってるけどこれでも減らそうとしてるのか

**デフォルトの名無しさん** · 2021/05/30(日) 16:00:13.57

もう9.5%も行ってるのか

と言うかfirefoxからrustは始まったから当然か

**デフォルトの名無しさん** · 2021/05/30(日) 16:15:38.02

でも、大量の有名なWebサービスが一時的にRubyで書いていたのに、
しばらくすると他言語に書き直した歴史がある。
アメリカ人はなぜか言語を書き直すのが好きなようだ。
Rustで書いてもまた別言語に直すかも知れない。
なお、Googleドライブなどの各社のストレージサービスを統一的なAPIで制御できる
ライブラリも何故かGoで書かれている。
メンドクサイ。

**デフォルトの名無しさん** · 2021/05/30(日) 17:11:41.17

>>781
遅い方から速い方へ書き直すのよ
特にスクリプト言語からC++/Rustへ書き換えるとサーバー数を1/10にできるケースもあり規模によっては経費激減ね
GoもGCあるから場合によっては他へ書き換えられる対象になりうるかも
Rustが他へ書き換えられる可能性がもしあるとしたら今はまだ存在しない新たに出現する言語へ

**デフォルトの名無しさん** · 2021/05/31(月) 00:35:54.04

なんでClippy大先生がcargoでインストールできるクレートから外されるの？

**デフォルトの名無しさん** · 2021/05/31(月) 01:50:13.82

rustupでインストールできるからでは
rustcとバージョン合わせないといけないから他のcrateと同じ扱いはしづらいのでは

**デフォルトの名無しさん** · 2021/05/31(月) 08:44:19.92

Ruby on Rails の時価総額は、

Shopify が15兆円、
民泊のAirbnb が、大手ホテル3社の合計以上の10兆円、
Github が8千億円

これぐらい巨大でも、Rails で出来る。
時価総額が千億円以上になったら、Go, Elixir を考えてもよい

食べチョクは売上50億円らしいけど、
若い文系女が1人で起業したような会社は、Rails で十分

売上が千億円を超えたら、考えてもよい

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/31(月) 15:24:48.93

ウェブシステム全体の実行コストはネットワークや IO にボトルネックが有るので
システム構成やらなんやらで工夫するのがまずやることで、
言語の速度が少しばかり速いのはそんなに効いてこないよ。

という話もよく聞くんだけど、実際のところどんなもんやろね？

**デフォルトの名無しさん** · 2021/05/31(月) 16:31:16.04

そりゃそうね
でも実行速度だけで選ぶわけじゃないからね

**デフォルトの名無しさん** · 2021/05/31(月) 19:40:04.29

今まではハードにぶん投げても大丈夫だったのが
ハードの進化の鈍化でソフト側が工夫しないと駄目になりつつあるって話ってマジ？

**デフォルトの名無しさん** · 2021/05/31(月) 21:37:16.00

いやそこでソフトで頑張ってもほぼダメだろ。。アーキテクチャで分散化考えないとって話じゃないかね

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/01(火) 01:05:37.48

>>788
ハードウェアがもう伸びないってことではなくて、 CPU の速度が単純に速くなるという方向ではもう伸びにくいって話。
電子の大きさは変えられないから際限なく微細化できるわけではない。

わかりやすい例で言えば今のパソコンはマルチコアが当たり前になってて複数の CPU を載せる方向で性能を上げているが、
マルチコアを想定してないソフトをマルチコアパソコンで動かしてもひとつのコアしか使わないので性能が出ない。
高価な GPU を乗せても GPU を使うプログラムになってなきゃ意味がない。

ハードウェアの総合的な性能を上げるには色んな工夫があり得て、それらを実現すると同時に
ソフトウェアは「ハードウェアに合わせて」「ハードウェアの性能を引き出すように」工夫がいる。

これは今までにも普通にやってたことで、今になって必要になったわけじゃない。
小さな変化の積み重ねなこともあれば大きな変革を迫られることもあるってだけ。

**デフォルトの名無しさん** · 2021/06/01(火) 07:44:50.11

後藤弘茂のWeekly海外ニュース■ Prescott/Tejasは5GHz台、65nmのNehalemは10GHz以上に
ttps://pc.watch.impress.co.jp/docs/2003/0227/kaigai01.htm
当時は景気よかったっすね。すぐ後に爆熱で日和ったけど
そして今、300Wの時代・・・

てか並列化によるスループットの向上はこのあたりから検討されるようになっていた気が

**デフォルトの名無しさん** · 2021/06/01(火) 19:29:09.48

>>784 でも何故かcargoだけはcargo install cargo --forceとすれば自分でコンパイルしたもので上書きができる謎

**デフォルトの名無しさん** · 2021/06/04(金) 15:33:30.83

よくわからないんだけどこれ、C言語のポインタ渡しが諸悪の根源で、そこを断ちさえすればC言語も所有権概念を取り入れられるの？

**デフォルトの名無しさん** · 2021/06/04(金) 15:42:09.57

>>793
C言語において、ポインタは大発明で、それによってリンクリストやツリー構造
が簡単に実装に出来る様になった、大変重要なもの。
C言語からポインタを絶てば何も残らない。

**デフォルトの名無しさん** · 2021/06/04(金) 15:48:43.92

Javaキチガイはポインタ使いこなせない
日本のMSの社員がソレだった
破棄忘れてやんのw

**デフォルトの名無しさん** · 2021/06/04(金) 15:55:06.60

RAIIなしで良いなら多少の拡張で所有権の概念取り込めるかも知れないけど
絶対スマートポインタ欲しくなるしCの表現力だと使いづらい物になりそうな気がする

**デフォルトの名無しさん** · 2021/06/04(金) 16:03:03.62

>>794
>C言語において、ポインタは大発明
笑笑

**デフォルトの名無しさん** · 2021/06/04(金) 17:24:32.39

Cと比較するのは流石に乱暴だろ
C++と比較するべき
で、C++でできなくてRustでできるものというのは現状存在しない (今後その差も埋まっていくだろうが)

C++とRustの違いはひとえにスタンスの違いだよ
自由奔放なC++か良いコードにカッチリ導いてくれるRustか
意欲的に新機能取り込んで発展してるのは両者とも同じ

**デフォルトの名無しさん** · 2021/06/04(金) 17:31:18.17

>>798
>C++でできなくてRustでできるものというのは現状存在しない
こういう比べ方はアホ
チューリング完全ならなんでもできるじゃんみたいなことになる
できるできないの線引きが恣意的

**デフォルトの名無しさん** · 2021/06/04(金) 17:54:18.33

>>799
バカアホじゃなくて、Rustでしかできないものの例を挙げてください
そうすれば一単語で反論の余地なく終わるんで

**デフォルトの名無しさん** · 2021/06/04(金) 17:58:01.49

C++は奇麗に描くと言うのが出来ない

**デフォルトの名無しさん** · 2021/06/04(金) 18:03:48.84

>>800
C++でできなくてRustでできるもの
から
Rustでしかできないもの
への華麗な転身www

**デフォルトの名無しさん** · 2021/06/04(金) 18:16:57.72

C++はMemory Safetyをコンパイル時に担保できない
Rustを使う一番の動機

**デフォルトの名無しさん** · 2021/06/04(金) 18:53:59.58

>>802 C++とRustの比較において｢C++でできなくてRustでできるもの｣と｢Rustでしかできないもの｣は同じ意味だから転身でもなんでもない
https://i.imgur.com/3svkdus.png

**デフォルトの名無しさん** · 2021/06/04(金) 19:11:16.95

Cloudflareの画像処理責任者を名乗る人も、これ以上C++ライブラリを増やすのはイヤでござると発言してるな

**デフォルトの名無しさん** · 2021/06/04(金) 19:23:30.63

>>804
C++とRust以外にも言語はたくさんある

**デフォルトの名無しさん** · 2021/06/04(金) 19:29:23.53

Rustのモジュール（ファイル分割）の仕組みはC++のヘッダー＋ソース（＋名前空間）より扱いやすいと思う
C++は分割コンパイルが主流だった歴史的経緯があるから仕方ないけど事前の宣言が必要なのは地味に面倒くさい

**デフォルトの名無しさん** · 2021/06/04(金) 19:43:15.38

>>806 この会話の流れではC++とRustの比較をしていたから

**デフォルトの名無しさん** · 2021/06/04(金) 19:58:10.76

ライフタイムによるメモリ管理はRustオンリーだろ

**デフォルトの名無しさん** · 2021/06/04(金) 20:12:39.71

マイナーな環境だとC++プログラムは様々な理由でコンパイルが通らないことがよくある
Rustは基本的にはそういう事ないし、コンパイラ実装が一つしかないというのも利点に働く

**デフォルトの名無しさん** · 2021/06/04(金) 20:40:42.82

C++との比較を議論したいなら専用の隔離スレでどうぞ

**デフォルトの名無しさん** · 2021/06/04(金) 22:02:04.46

>>793は言語レベルのサポートがほしいんだろ？
substructural type systemがないと無理。

>>809
MLkit,RTSJ,cyclone,ATS/ATS2。学術的にはとっくの昔に廃れたぞ。

**デフォルトの名無しさん** · 2021/06/04(金) 22:04:58.58

WinUIとRustやってる人いる？
同じネイティブのMFCとかと比べて、やっぱり生産性は高いんかな

**デフォルトの名無しさん** · 2021/06/04(金) 22:26:52.09

メモリ関連って原因不明のバグ引き起こしやすいしトータルな目で見れば上がるんじゃないだろうか

**デフォルトの名無しさん** · 2021/06/04(金) 23:27:29.47

>>810
gcc-rsとかのプロジェクト始まってるけどそれはネガティブなことなのかね

**デフォルトの名無しさん** · 2021/06/05(土) 06:04:54.16

>>810
そういえば、C++のSTLは、VSでは動くが、BSD系のLLVM用のlibc++は、
なかなか上手く動いてくれない。理由は、libc++が、その
基礎関数として滅多に使われないようなMB・WC文字変換関連や、
NAN、INFINITYなどのfloat/double調査関数など、昔ながらのC環境では
定義されて無いような(新しい)Cの関数を大量に必要としているため。
その意味で、WasmのWASIなんかは、たとえCUIだけであっても
世界共通の関数群を整備してくれるのだとしたら有りがたいかも知れない。
でもWASI自体の移植作業が必要になるから一緒か。

**デフォルトの名無しさん** · 2021/06/05(土) 06:14:19.54

>>816
昔からCには文字種判別として、isalphaやisdigitなどがあるが、
libc++は、isalpha_l()などのlocale指定タイプを必要としていたりして
locale関連がやたらと複雑。また、その
isalpha_lなどを基礎にしてくれているならまだしも、isalpha_lが内部で使っている
文字種テーブル unsigned short _ctype[256]; も仮定していたりする。
このテーブルは、_CONTROL、_SPACE、_DIGIT、_ALPHAなどの
BIT定数とandを取ってBITが立っているかどうかで文字種を判定する。
それは環境依存なのだが、高速化のためか何故かそれを必要としている。
(C++のライブラリが欲しいのに、そのライブラリが、なぜか一般的ではない
大量のC関数や特殊なデータテーブルを必要としてしまっている。)
だから移植が進まない。
plain Cは、標準ライブラリが多くの環境である程度の互換性を持って整備されているが、
結果的にC++のSTLはなかなかそうではないようだ。

**デフォルトの名無しさん** · 2021/06/05(土) 06:17:47.83

C++ライブラリがisalpha_lなどを用いてしまったら、速度面でC#やJavaなど
に比べた優位性が少なくなってしまうからかも知れない。
つまり高速化のためにやたらと移植性の低い方法を使っているから、
スムーズに移植が進まない。
それか単純にC++ライブラリを作る人の技術力が低いからだろうか？

**デフォルトの名無しさん** · 2021/06/05(土) 06:20:08.28

>>801
すまんが、Rustはもっと出来ない気がする。

**デフォルトの名無しさん** · 2021/06/05(土) 09:02:04.60

RustスレでC++の話題が出てしまうのはもはや運命なのか

**デフォルトの名無しさん** · 2021/06/05(土) 09:20:03.77

>>820
そりゃ better C++言語として作られたんだから当たり前でしょう

**デフォルトの名無しさん** · 2021/06/05(土) 09:32:35.80

ライフラインの書き方がとにかく見づらい

**デフォルトの名無しさん** · 2021/06/05(土) 09:45:07.09

これヤバくない？
どうやって防いだらいいんだろう？

https://github.com/lucky/bad_actor_poc

**デフォルトの名無しさん** · 2021/06/05(土) 09:46:58.65

localhostに送るだけならいくないん？

**デフォルトの名無しさん** · 2021/06/05(土) 09:53:33.78

え、マジで言ってるの？

**デフォルトの名無しさん** · 2021/06/05(土) 10:04:24.16

あおられてもダメな理由がわかりまそん
びっくりはするけど

**デフォルトの名無しさん** · 2021/06/05(土) 11:21:46.59

悪意を持ったコードをビルドしない

**デフォルトの名無しさん** · 2021/06/05(土) 12:04:01.08

c++との比較はガファムが結論出してくれたからもう話すことなどない

**デフォルトの名無しさん** · 2021/06/05(土) 12:08:54.56

何をみて結論だと思ってんだか。短絡的だな。

**デフォルトの名無しさん** · 2021/06/05(土) 12:26:06.61

依存するクレートの依存するクレートの依存するクレートの以下無限ループまで全部チェックしないと駄目ー？(´・ω・｀)

**デフォルトの名無しさん** · 2021/06/05(土) 12:58:14.11

チェックするツールとか誰か作っていそうだね
バイナリを診断するよりは簡単だろうし

**デフォルトの名無しさん** · 2021/06/05(土) 13:57:18.40

>>826
念のためマジレスすると公開した人がいつでもlocalhostを〇国サーバーのアドレスに書き換えられるってこと
githubのオープンソースでそれやったらすぐにばれそうだけど

ビルド時ならともかくエディタ起動直後のコード解析でデータが送信されるのは盲点やね

**デフォルトの名無しさん** · 2021/06/05(土) 14:01:47.49

ビルドしなくてもファイルを開いたらコードが実行されるというのはよろしくないね

ファイルやネットワークならアクセスされる側でブロック可能だけど
メモリはサンドボックス内のみで展開・実行されるようにしないとブロックできない気がする

サンドボックス化できなければ
cargo auditやcargo crevを通して怪しいcrateだけ自分でチェックするとかかな

**デフォルトの名無しさん** · 2021/06/05(土) 14:06:05.14

vscodeやlspヤバイな

**デフォルトの名無しさん** · 2021/06/05(土) 14:13:31.58

解決方： vscode を使わない

**デフォルトの名無しさん** · 2021/06/05(土) 14:27:34.92

まったくだ