エラーメッセージにおけるcontextとsourceを明確に区分する

[qryxip]

内容

#580 で宣言した以下のことをします。

• Display実装にはsourceの内容を含めない

関連 Issue

#580, #589, #600, #622, #623 の続きです。

ref #545

その他

(これは慣習としてどこかで明文化されていたはずですが、それがどこなのかを忘れました)

と書いてたのですが、これです。

• https://blog.rust-lang.org/inside-rust/2021/07/01/What-the-error-handling-project-group-is-working-towards.html

  An error type with a source error should either return that error via source or include that source's error message in its own Display output, but never both.

• Guidelines for implementing Display and Error::source for library errors rust-lang/project-error-handling#27 (comment)

  • Return source errors via Error::source unless the source error's message is included in your own error message in Display.

[qryxip]

ここの数十行下にFIXMEとして書いたが、このLoadは元々機能しておらず、システム辞書の読み込み失敗はNotLoadedOpenjtalkDictに統合されていた。

[Hiroshiba]

LGTM！！

変更してもしなくても良さそうなコメントだけいくつか！

[Hiroshiba]

めちゃめちゃ細かいですが、意外と解釈という言葉はドキュメントに出てこない気がしました。
正確にはメモリ足りなかったとかもあり得る気がするので、処理とかで良いかも。
（まあ解釈でも別にいいかな、くらいの温度感です）

[qryxip]

"could not interpret"のような文であれば世に溢れていると思ってました。

OOMについては... そもそもOpen JTalkは考慮しているんでしょうか? なんかC++の例外とかがそのまま発射されそうな気も... (ちなみにそんなことがもし起きた場合、Rust的にはUB)

[Hiroshiba]

あ、OOMは例えでした。
extract_fullcontext関数が失敗した==解釈に失敗した、ではない可能性があるなと思った次第です。
これが真かどうかはOpenJTalkAPIのドキュメントがないのでコードの深いとこまで読まないとわからないだろうから、含みを持たせた方が正確かなぁくらい。

[Hiroshiba]

大きな問題はないと思うのでマージします！