group_imports=StdExternalCrateでRustfmtをかける
#466
Comments
|
importの順番が一意になる感じですよね。 基幹部分にnightly使うのはだいぶ危うそうですが、formatterだけならありだと思います。 あるいは同等のことをするサードパーティライブラリがあるなら、そちらに依存するのもありかもです。 |
はい。必要ですね... |
Rustfmtくらいしか多分無いですね... Rustfmtではないフォーマッタとしてはprettypleaseというものがあるのですが、これは機械的に生成された数千数万行のコードを破綻無くフォーマットするための用途で用いられており(例えば我々がonnxruntime-rsやopen_jtalk-rsで使っているbindgen)、 |
|
なるほどです。 流石にnightlyは難しいかなと思いました！ |
|
nightly入れるとしたら、 参考までに、サニタイザとかcargo-udepsとかの他のnightly依存のツールも避ける方針でしょうか? メリット次第? |
単純にここら辺のコスト感覚を共有しておきたいなと思いました。 |
|
あと「nightlyなRustのインストールが必要」の時点で、もしかしたらですがコストについて齟齬が発生していそうな予感もしています。 私が考えているのはCIでのみnightlyにする方針ですが、仮に手元でやりたくなったときも ❯ rustup install nightlyとだけ実行すれば60MiBくらいのダウンロードの後Nightly Rustが使えるようになります。pyenvやnvsにあたるものは標準搭載です。 |
|
・コード実行するRustがnightlyになるのは避けたい ただ、開発者にとって「フォーマッターがないのにCIが落ちる」のはストレスになりそうです。 |
|
はい、そうです |
|
なるほどです！ nightlyは相当不安定なことがあり得るのでできれば避けたいかもです。（できればです） |
|
開発者のストレスについてですが、Reviewdogから言われる形であれば軽減できるかもしれません |
|
どこを修正すればよいかわかるから、でしょうか？ |
|
案内というより、reviewdogならsuggestionまで出せるんじゃないかと思っています。 |
あ、betaには入っていないですね...状況はこんな感じです。 |
|
なるほどです、suggestionまで出せるなら結構ありかもと思いました！！ CIに入れてreviewdogでsuggestion出してもらう、という体験をしてみたいです･･･！！！ |
|
あーsuggestion対象は選べても、そのsuggest内容は厳しいですね...10行離れてたりすると... あとそれ以前の致命的な問題に気付いてしまいました。Rustfmtの struct A;
mod sub {
struct B;
mod sub {
use std::cmp::Reverse;
use itertools::Itertools;
use crate::A;
use self::sub::C;
use super::B;
mod sub {
pub(super) struct C;
}
}
}
use std::cmp::Reverse;
use itertools::Itertools;
use self::sub::C;
use super::B;
use crate::A; |
|
まあこのissueの主題とは別にClippyとかactionlintの方でreviewdog使うというのはありなのではと思ってきました。 sksat/action-clippyというのを用意している方がブログにこんなことを書かれていますし、このリポジトリにPRしに来てくれるRust初心者の体験をマシにできるんじゃないかなーと思っています。
|
|
あ～なるほどです。 それはそれとして、reviewdogは興味があります！！ |
いえ、Rust Analyzer式で揃えた筈の
まあ |
|
なるほどです！！ nightlyのフォーマッターを導入するかの判断について優先順位が高い順に整理していくと
ということかなと。従うと
ですかね！ |
|
あ。
という提案頂いてたの見逃しました。 |
|
「Rust Analyzer式」のと互換性が無いですね...まとめるとこんな感じです。
|
|
あとRust Analyzer式group importsですが、rust-lang/rust-analzyerのPR/issueコメント以外にドキュメントは多分存在しないですね... Rust Analyzerは婉曲的に表現するとかなりフットワークが軽いので、しれっとデフォルトの挙動が変更されるかもしれません。 なのでRust Analyzer式で一度だけフォーマットし、CIの設定やドキュメントの記述はせずに、以後しばらくの間は(qwertyさんやSuitCaseさんも含めて)PRに対する突っ込みは一切入れない、というのが丸いのかなと今は思っています... |
|
なるほどです！ 一旦closeで良さそうでしょうか？ |
|
まあ一旦closeしてもよさそうですね。 |
|
まあRustの // Rust Analyzerが「なんだこれ」と思ってしまうのか、無視して別のgroupを作り始めてしまうという欠点はある
use {
self::sub::C,
super::B,
crate::A,
::{
anyhow::{bail, Context as _},
itertools::Itertools as _,
octocrab::{
models::{
repos::{Asset, Release},
AssetId,
},
Octocrab,
},
std::{
borrow::Cow,
env,
future::Future,
path::{Path, PathBuf},
sync::Arc,
time::Duration,
},
},
};Rustfmtが強権をふるえば話は別でしょうけど、version 1を宣言したRustfmtがデフォルトの挙動を変更できるはずがなく... Rust Analyzerが"Reorder import groups"みたいなcode actionを用意すれば統一のきっかけにはなるかもしれない、という程度ですね。 |
内容
--config group_imports=StdExternalCrateでRustfmtをかけます。#237と類似したものです。現在このリポジトリの
useのスタイルは、qwertyさんが書いたのとSuitCaseさんが書いたのと私が書いたので混沌とした状態になっています。これを一つに統一します。StdExternalCrateである理由は、Rust Analyzerが(現在のところ)アイテムの自動インポートを行うときにそのようなスタイルで追加してくるからです。Pros 良くなる点
現在このリポジトリには統一されたルールなんてものは無いわけですが、初めて来た人にとってはそのことは自明ではなく、ほんのちょっとだけ混乱する要素になるかなと思っています。
Cons 悪くなる点
ただしNightly Rustには他に使い道がいくつかあります。
実現方法
cargo +nightly fmt -- --config group_imports=StdExternalCrategroup_imports=StdExternalCrateをチェックするようにするVOICEVOXのバージョン
N/A
OSの種類/ディストリ/バージョン
その他
The text was updated successfully, but these errors were encountered: