search

sakura-editor / sakura

SAKURA Editor (Japanese text editor for MS Windows)
https://sakura-editor.github.io/
Other
1.24k stars 162 forks source link

ヘッダのプロトタイプ宣言で変数名が省略されて型名しかないものに明示的に変数名を指定する #224

Open m-tmatma opened 6 years ago

m-tmatma commented 6 years ago

ヘッダのプロトタイプ宣言で変数名が省略されて型名しかないものに明示的に変数名を指定する

例えば以下部分

https://github.com/sakura-editor/sakura/blob/a1f053c55d5bb1617c15836f97315284425f8f90/sakura_core/cmd/CViewCommander.h#L121

cpp では以下のように定義されている。

https://github.com/sakura-editor/sakura/blob/a1f053c55d5bb1617c15836f97315284425f8f90/sakura_core/cmd/CViewCommander_File.cpp#L596-L603

m-tmatma commented 6 years ago

他の PR とかぶると嫌なので調査だけしておく。

m-tmatma commented 6 years ago

何らかのツール、コンパイラ等で検出できたらいいのだけど

m-tmatma commented 6 years ago

こんな情報があった。根拠には疑問を感じるが。 https://www.jpcert.or.jp/sc-rules/c-api08-c.html

berryzplus commented 6 years ago

根拠に挙げられた障害への対策は、できるだけマクロを使わないとか汎用的に使われる名詞にマクロを割り当てないとかになるような気がしました。公的推奨も結構いい加減ですねぇｗ

ちなみにこの件、intellisenseの拡張apiを使えばなんとかなるような気がしています。ツールを作るかどうかは優先度によるのかな、と思っています。

berryzplus commented 6 years ago

保留中 #326 を解決するために、関数宣言に引数を付ける対応が必要かも知れません。

いまのところ、対応方法は ~二択~ 三択だと思っています。

No 方法 メリット デメリット
1 手作業で追記 すぐに着手できる レビューが困難
2 ツール化する ~すぐに着手できない~ レビューが楽 ~レビューが楽~ すぐに着手できない
3 既存ツールを使う 修正＆レビューが楽 使えるツールがあるか分からない

　※8/26 No3を追加しました。

追記箇所の数が多いので「ツール化」で進めたい感じです。

ツール化する場合のアプローチは3つだと思っています。

どの方式をとったとしても一度作ってしまえば、 他の目的に流用できる余地があると思っています。

普通に考えるとVSIXは修羅道です。 ただ、流用前提で考えるとVSIXは少しの変更で様々なニーズに対応できます。 理想をいえば VSIX、手軽さでいけば完全独自、悩ましいところです。

m-tmatma commented 6 years ago

no 2 のメリットとデメリットが逆のような気がします

m-tmatma commented 6 years ago

案4 clang-tidy とかのツールでできるのならそれで、 できなくても、clang-tidy が使用している LibTooling というライブラリを使ってツールを書く

↑ 実現可能かは全く調べてません

http://clang.llvm.org/extra/clang-tidy/ http://clang.llvm.org/docs/LibTooling.html

m-tmatma commented 6 years ago

↑ 誤植修正

berryzplus commented 6 years ago

no 2 のメリットとデメリットが逆のような気がします

修正してみました。

案3は「既存ツールでできる」ということ？

m-tmatma commented 6 years ago

できるかはわからないです。

berryzplus commented 6 years ago

できるかはわからないです。

了解です。表を更新してみました。 まず、そういうツールがあるか探すところからですね。 とりあえず、貼ってもらった llvm のツールを見て見ます。

k-takata commented 6 years ago

プロトタイプ宣言を自動生成するツールとして cproto というものがあり、Vimでも使っているのですが、さほど使いやすくもない (特にWindows) のが残念なところです。

m-tmatma commented 6 years ago

できなくても、clang-tidy が使用している LibTooling というライブラリを使ってツールを書く

libclang というライブラリで clang のコンパイラ機能を使えるみたいだ。 解析はできるみたい。変更ができるかは不明。

python binding や c# 向けのライブラリがあって、プログラムから呼び出せる模様。 https://qiita.com/subaru44k/items/4e69ec987547011d7e63 https://qiita.com/atsushieno/items/f561c5d3c5308545c4f3

m-tmatma commented 6 years ago

libclang を使うには clang でビルドできるようにはしとく必要があるとは思う。

berryzplus commented 6 years ago

llvm(=clang)のツールを見て見た感想・・・

VSIXでVC++のエラー一覧にタスクを突っ込むのと考え方が同じっぽい。 10年くらい前に Eclipse のプラグインも触ったことがあるんですが、 目的が同じだと考え方やコードも似るようです。

llvm で windows アプリ を作れるものなのかどうかは、よく知らないです。 vs2017がclang/llvmのビルドに対応していることと、 llvm で windows アプリ をビルドできるか？の間に関連性はないはず・・・。 （最近のvc++はクロスコンパイル環境としても使えるから。）

m-tmatma commented 5 years ago

何らかのツール、コンパイラ等で検出できたらいいのだけど

完璧ではないですが、検出ツールを作成中です。 このツールで検出して、手動で変更する方向で検討中です。

https://github.com/m-tmatma/GrepFuncProtoType

GrepFuncProtoType.sln をビルドして、 以下を実行したら該当箇所を絶対パスと行番号付きで出力します。

GrepFuncProtoType.exe <ソースコードのあるフォルダパス>

visual studio の外部ツールに

コマンド → GrepFuncProtoType.exe の絶対パス 引数 → $(SolutionDir)

を指定して、登録した外部ツールを実行すれば、visual studio の出力ウィンドウに検索結果を表示します。 出力ウィンドウの該当箇所をダブルクリックすれば、該当箇所にジャンプします。

m-tmatma commented 5 years ago

↑ 現状では constや &や *を含む場合などは非対応です。 また、ある引数は、仮引数があるが、同じ関数の別の引数は非対応といったように 混ざった状態も非対応です。

berryzplus commented 4 years ago

一年以上も前の話だったのか！と気付くなど:sob:

↑ 現状では const や & や * を含む場合などは非対応です。 また、ある引数は、仮引数があるが、同じ関数の別の引数は非対応といったように 混ざった状態も非対応です。

  1. 引数型にconst修飾(=読み取り専用)が付いていたり、
  2. 引数型が参照(=‘std::wstring &`型など)だったり、
  3. 引数型がポインタ(=wchar_t*型など)たったりすると使えない、
  4. 引数が2つ以上あるメソッドの場合、全部の引数で引数名が欠落してないと修正されない ってことですかねぇ・・・。

サクラエディタのコードってそんなんばっかな気がしないでもないですが :cry: