Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[project-vvm-async-api] いくつかのC関数を定数にする #503

Conversation

qryxip
Copy link
Member

@qryxip qryxip commented May 27, 2023

内容

C APIのいくつかの関数を定数にします。

関連 Issue

その他

@qryxip qryxip changed the title いくつかのC関数を定数にする [project-vvm-async-api] いくつかのC関数を定数にする May 27, 2023

/// voicevoxのバージョンを取得する
/// @return SemVerでフォーマットされたバージョン
/// voicevoxのバージョン
Copy link
Member Author

@qryxip qryxip May 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

なんかcbindgenがこういう定数へのdocstringを拾ってくれない...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

悲しいですね・・・
そのオプションを使う関数の方にメモを書くことになるのかなと思いました。。 😇
(ユーザー的にはそちらの方が便利かも)

ちょっと面倒かもしれないんですけれどもお願いできますか 🙇‍♂️

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cbindgenのドキュメントを探しても何故こうなっているかの理由は見つけられませんし、issueもそれっぽいものは無さそうです。#defineによる定数だとちゃんとrustdocを引き継ぐのも変ですし、もう少し調べてみます。

/// ああああああああああ
pub const N: i32 = 42;

/// ああああああああああ
#[no_mangle]
pub static M: i32 = 42;

/**
 * ああああああああああ
 */
#define N 42

#ifdef __cplusplus
extern "C" {
#endif // __cplusplus

extern const int32_t M;

#ifdef __cplusplus
} // extern "C"
#endif // __cplusplus

Copy link
Member

@Hiroshiba Hiroshiba Jun 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

不思議ですね・・・。
よくよく考えたらstaticにしておく理由は特にない?ので、define(const)でもいいかもとかちょっと思いました。
全部大文字にしないと不自然かもで、可読性は落ちるかもですが 😇

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#defineにしたらヘッダー(つまりAPIの「形式」)にだけ"0.15.0"みたいな情報が埋まって、DLL本体から情報が抜けるのではと思います。

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

意図が読めてないのですが、抜けるから不便or良いどちらでしょうか?

Copy link
Member Author

@qryxip qryxip Jun 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

不便の方ですね。

そもそも他言語バインディングを作るときなんかは必ずしもヘッダーを直接読んだりしないでしょうし、読むとしてもOptions系をちゃんと解釈できるか怪しいと思います。あとバージョン不明なvoicevox_core.dllのAPIを叩いてバージョンを調べる、といったことも不可能になると思います。
(追記) compatible_engineとかdeprecatedな方を叩けばいけるかもしれませんが...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

なるほど!
たしかにバインディング作るときはたしかにdefineを自分で書かないといけなくなりますね・・・。

諦めるか、関数に戻すか、半分あきらめつつissue建てるかでしょうか。
個人的には半分諦めてissue建てるのが落とし所かなと思いました。

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

なんか"IR"としてはちゃんとdocstring部分を拾っているようです。

https://github.com/mozilla/cbindgen/blob/3680e4d539e33977d613f161530c91a284a82428/src/bindgen/ir/global.rs#L25

そしてこれを消してもコンパイルは通る!!!

crates/voicevox_core/build.rs Outdated Show resolved Hide resolved
crates/voicevox_core/build.rs Outdated Show resolved Hide resolved
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

型パートでの型の順番が何故か入れ替わっている...

crates/voicevox_core/src/result_code.rs Show resolved Hide resolved
crates/voicevox_core/src/version.rs Show resolved Hide resolved
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

アイテムの順番が.hでのものと異なっている(cbindgenは型→定数→関数の順で並べる)ので、.h側に合わせる形で並び換えるのがいいかもしれない。

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

関数とかの属性よりも扱っている概念でまとまっていたほうがわかりやすいだろうなーとは思いつつも、ヘッダー側と並び順が違うのはあとで見づらい気もしますねぇ。
まあヘッダーと並び順が違うことで困る人は珍しいし、個人的にはこのままのが良いのかなとか思いました。

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

並び順自体が違うこと自体はいいとして、ヘッダー側の並び順を制御するのに今後困ることがありそうな予感がしています。今回こういう↓よくわからないことが発生していますし。
#503 (comment)
どっちにしろmainとの差分は凄いことになるので、もうdiffが60%を超えることを前提にがっつり入れ替えてもいいんじゃないかと思いました。

もう一つの方針として、(そもそもできるかどうかわかりませんが)ヘッダー側を「扱っている概念でまとまってい」る並び順にするというのが考えられますが、最終的にはこういう形のドキュメントを生成してユーザーに提供することになるので、無理が出てくると思います。

Copy link
Member

@Hiroshiba Hiroshiba Jun 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

基本的にC側に合わせるのは得策ではないと思っています。
ユーザーは困らない、API追加のたびにヘッダー生成して順序合わせる作業が発生して大変、コードが読みづらくなるためです。
順序違いは諦めるか、C側をRust側に合わせるのを目指すのはどうでしょう。


論点がいくつかあっていろいろ混じってるように思うので考えを整理して書いてみました。

  • Rust側とC側でドキュメントの順序が異なるのをどうすべきか
    • 合わせないで良いと思う
      • 困る人がいないため
      • ヘッダーの順序は生成されるまで不明で新規コミットが大変なため
    • どちらかというとC側が古い
      • 関数等の型で並べるよりエンジンAPIみたくドメインで並べたほうがいい
    • 合わせられるなら合わせたい
      • 整合性取れてるか判断するためにコミッターとレビュワーがちょっとなため

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

その2つだと諦める方向ですかね...
C側の順序をなんとかしようとするとcbindgenとDoxygenの両方をどうにかしないといけないので、大変な気がします。

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

実装の難度やユーザーの需要はともかく、メンテコストの認識には微妙に齟齬がありそうな気がします。

ヘッダーに関しては #493 でこのリポジトリに追加されているため、手元で

cargo xtask update-c-header

ってやれば更新できるのでそれをgit diffで見ればいいと思います(readmeに一応書いてありますし、CIも回っています)。私は今実際にそうやっています。

コードの可読性については、そもそもlib.rsはAPI視点のシグネチャとドキュメントを中心にした方がいいのではないでしょうか。今あるhelpers.rsとc_impls.rsの2つは実装を分離させるためにあるはずです。

tree crates/voicevox_core_c_api/src/
crates/voicevox_core_c_api/src/
├── c_impls.rs
├── compatible_engine.rs
├── helpers.rs
└── lib.rs

1 directory, 4 files

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

実装→ヘッダー作成→順序変える、ですよね。たしかにそこまで手間でも無いかもですが、意味が薄い作業(困る人がいないため)を手間かけてやらないといけないのはデメリットではあると思います。

コードの可読性については、そもそもlib.rsはAPI視点のシグネチャとドキュメントを中心にした方がいいのではないでしょうか

ドキュメントは使う側のために作っているもので実装側はあまり見ないので考えなくて良いはずです。
実際エンジン側ももう1年ほどずっとドキュメント順序と実装順序が別ですが、問題だと感じたことがなかったです。

実装順序とドキュメントの順序が違うの、全然普通な気がしてきました。
例えばPythonのpathlibを見た感じ、実装ドキュメントで全然違いそうです。

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

実装とドキュメントが違うのは一般的だとは思います。Rustdocもソースコード上の順番に関わらずアルファベット順になりますし。私が問題だと思っているのはCでは上から下に定義を書かなくてはいけないために、このPRのようなことをするとcbindgenが荒ぶることです。

いっそのことCヘッダー側をアルファベット順でソートするのはどうでしょうか? cbindgenにはそういうオプションはあります。ドメインの区分けがわからなくなりそうですが、ドキュメントをコード例と共に手厚く書いてquickstart的なものも用意すれば大丈夫なはずだと思います。

Copy link
Member

@Hiroshiba Hiroshiba Jun 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

なるほどです。今回のように型が変わって順番が変わるのは破壊的変更があるときくらいなので、そもそも破壊的変更が大きいから問題とまではいかない気がしました。

名前順でも別に良いと思います。
ユーザーにとって一番困るのは運営が明確な意図なくポンポンいろいろ変えてくることだと思うので、しっかり意図を考えておきたいかもです。
「今後ドキュメントの見た目が大きく変更されなそうだから」とかですかね。

@qryxip qryxip marked this pull request as ready for review May 28, 2023 08:38
Copy link
Member

@Hiroshiba Hiroshiba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

いくつかコメントしていますが、ほぼLGTMです!!

@qryxip
Copy link
Member Author

qryxip commented Jun 3, 2023

#507 のコンフリクト解消はしたので、あとはversionのあれこれの取りやめですね
(コンフリクト解消はiPadのブラウザでやりました)

@qryxip
Copy link
Member Author

qryxip commented Jun 3, 2023

あーduplicateクレートのやつもありましたね。draftにしときます

@qryxip qryxip marked this pull request as draft June 3, 2023 09:07
@qryxip qryxip marked this pull request as ready for review June 4, 2023 13:23
Copy link
Member

@Hiroshiba Hiroshiba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

あとはstaticのドキュメント書かれないのどうするかと、ヘッダーの並び順変わるのどうするかが議論ポイントって感じでしょうか。
いったんプルリクのタイトルのことは達成できてますし、とりあえずマージしちゃってタスクに積んでおくのも別にいいかな〜と思います。
@qryxip さんのやりやすい方で・・・!!!

@qryxip qryxip mentioned this pull request Jun 6, 2023
67 tasks
@qryxip
Copy link
Member Author

qryxip commented Jun 6, 2023

そうですね。タスクリストに入れておきました。cbindgenは腰を入れて調べないといけない気がします...

Copy link
Member

@Hiroshiba Hiroshiba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!!!

Rustの勉強になりました、ありがとうございました!!

@Hiroshiba
Copy link
Member

@PickledChair Rust周りのこととかコメント頂けると心強いのですが、お時間どうでしょう・・・? 👀

@qryxip
Copy link
Member Author

qryxip commented Jun 7, 2023

このPRを実装するにあたり、soundnessについて私が考えていたことです。
まあこの辺は書かんでもいいでしょと思っていたのですが、SuitCaseさんがレビューしてくださるなら取り急ぎ書いておきます:

  • no_mangle…Optionsの定数を宣言してよいのか?
    • よい。プリミティブ型でなければならないといったルールは無いはずで、"FFI-safe"であるならよいはず
  • no_mangle&strの定数を宣言してよいのか?
    • よい。&T*const Tとして扱える
      • もっと言えばOption<&T>とかも*const Tとして扱ってよい
      • alignedかつShared XOR Mutableルールから逸脱していなければ*const T&Tとしてよい

不明な点や他の疑問があったら遠慮なく聞いて下さい。

@PickledChair
Copy link
Member

@Hiroshiba

@PickledChair Rust周りのこととかコメント頂けると心強いのですが、お時間どうでしょう・・・? 👀

ちょっと思ったより最近忙しいので時間が取れてなくてすみません。ざっとみた感じでは問題なさそうでした……!

@qryxip

この辺は書かんでもいいでしょと思っていたのですが、SuitCaseさんがレビューしてくださるなら取り急ぎ書いておきます:

情報ありがとうございます! 私も多分問題ないと思います。

@PickledChair
Copy link
Member

問題ないと思うのでマージします。cbindgen の問題について #503 (comment) の方もありがとうございます

@PickledChair PickledChair merged commit f4b502a into VOICEVOX:project-vvm-async-api Jun 7, 2023
@qryxip qryxip mentioned this pull request Jul 22, 2023
69 tasks
shigobu pushed a commit to shigobu/voicevox_core that referenced this pull request Jul 31, 2023
This reverts commit f4b502a.

# Conflicts:
#	Cargo.lock
#	Cargo.toml
#	crates/voicevox_core/Cargo.toml
#	crates/voicevox_core_c_api/Cargo.toml
#	crates/voicevox_core_c_api/include/voicevox_core.h
#	crates/voicevox_core_c_api/src/lib.rs
qryxip added a commit that referenced this pull request Aug 13, 2023
Co-authored-by: Ryo Yamashita <[email protected]>
Co-authored-by: kasamatsu <[email protected]>
Co-authored-by: shigobu <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants