e2 studioでビルドエラーが無いのに編集エラーが表示された時に試すと良いかも(workarounds for INDEXER/CODAN troubles)

こんにちは、NoMaYです。(すみません。7つに小分けして投稿します。)

e2 studioやEclipse/CDTでは、ビルドはエラー無く完了するのに、どういう訳か編集ウィンドウにエラーが表示されてしまうことがあります。今までずっとちょっと腑に落ちなかったのですが、別スレッドでの投稿をきっかけに1週間ほど調べてみて、まとまりの良さそうなところで一区切り付きましたので、分かったことを投稿します。(すみません。後でリンクを追加するかも知れない時にContent Under Reviewとならないよう少しマージンが欲しかったのと、画面コピーが多くて切れ目が分かり難いのとで、7つに小分けして投稿します。)

ビルドはエラー無く完了するのに、どういう訳か編集ウィンドウでエラーが表示されてしまう


この症状にはe2 studio(というかEclipse/CDT)のインデクサー(INDEXER)とコード解析(CODAN)という2つの機構が関係している(のは間違いないと思われる)のですが、調べているうちにe2 studio(というかEclipse/CDT)のワークスペースの設定をデフォルトから以下へ変更しておいた方が良さそうだということに気付きました。(理由は4つ後の投稿にて。)

ワークスペースの設定では Index all header variants を 有効 にしておいた方が良さそう


また、ワークスペース内に複数のプロジェクトがある場合には、他のプロジェクト、特に品種が異なるマイコンのプロジェクト、すなわちプロジェクト内のiodefine.hが異なるプロジェクト、を閉じておいた方が良さそうだということにも気付きました。(理由は6つ後の投稿にて。)

複数のプロジェクトがある場合、品種が異なるマイコンのプロジェクトは閉じておいた方が良さそう



更に、3つ後の投稿に書いたeclipse.orgのウェブサイトで見付けた情報からすると、利便性よりも、編集ウィンドウに原因不明のエラーが表示されないようにすることを優先したい場合には、以下の3つは無効にしておいた方が良いかも知れません。(もっとも、無効にしても、自分でメイクファイルを書いたのでなければ利便性はそれほど損なわれない、ような気がします。)

無効にしておいた方が良いかも知れないインデクサーオプション:
すべてのファイルに索引付け(ビルトもインクルードもなし) (英語表記 Index source files not included in the build)
未使用のヘッダーを索引付け (英語表記 Index unused headers)
Allow heuristic resolution of includes


ちなみに、トラブルを解決するヒントを与えてくれるかも知れないものとして、パーサーログファイルというものがあります。これは以下のようにして生成させることが出来ます。




resetprg.c.parser.log

Project:               rx64m_rsk_audio
File:                  file:/C:/Renesas/RX/issue_20170918/workspace_e2v600/rx64m_rsk_audio/r_bsp/board/rskrx64m/resetprg.c
Language:              GNU C
Index Version:         206.0
Build Configuration:   HardwareDebug
Context:               file:/C:/Renesas/RX/issue_20170918/workspace_e2v600/rx64m_rsk_audio/r_bsp/board/rskrx64m/resetprg.c
   C, {}
Versions in Index:     1
   C: {}; 5 macros, 2 includes, 240 names;

Include Search Path (option -I):
   E:\tools\micom\Renesas\CS+\CC\CC-RX\V2.03.00\\include
   C:\Renesas\RX\issue_20170918\workspace_e2v600\rx64m_rsk_audio\src
   。。。途中省略。。。
   C:\Renesas\RX\issue_20170918\workspace_e2v600\rx64m_rsk_audio\r_usb_hmsc\src\inc

Macro definitions (option -D):
   far=
   near=
   _far=
   _near=
   __BITRIGHT=1
   __CCRX__=1
   __DBL8=1
   __DOFF=1
   __evenaccess=
   __far=
   __FPU=1
   __INTRINSIC_LIB=1
   __LIT=1
   __near=
   __RENESAS_VERSION__=0x02030000
   __RENESAS__=1
   __RON=1
   __RX=
   __RX600=1
   __RXV2=1
   __STDC_HOSTED__=1
   __STDC_VERSION__=199901L
   __UBIT=1
   __UCHAR=1

Macro definitions (from language + headers in index):
   bool=_Bool
   brk()=_builtin_brk()
   BSC=(*(volatile struct st_bsc __evenaccess *)0x81300)
   BSP_BCLK_HZ=(BSP_SELECTED_CLOCK_HZ / BSP_CFG_BCK_DIV)
   。。。途中省略。。。
   ___BSP_PRV_IEN(x)=IEN ## x

Macro definitions (from files actually parsed):
   BSP_DECLARE_STACK=
   FPSW_init=(0x00000000)
   FPU_DENOM=0x00000100
   FPU_ROUND=0x00000000
   PSW_init=(0x00010000)
   PSW_init=(0x00030000)

Written on Mon Sep 25 06:16:06 JST 2017

 

Parents
  • 前の投稿では、ちょっと作為的なソースで試したのですが、同じような症状は、ワークスペース内に品種が異なるマイコンのプロジェクトを混在させた場合にも発生してしまうようです。(というか、最初にそのことに気付いた後、もっと簡単なプロジェクトでも同じような症状が発生することを確認してみた、というのが実際の順序でした。)

    たぶん、ワークスペースの設定でIndex all header variantsを有効にしても、その設定の対象となるものはマクロ定義のみで、構造体や共用体、或いは列挙体やtypedefとか、更にはC++のクラスなど、といったものは対象外なのではないかと思われます。つまり、これらに関しては、ワークスペース内に同じ名前で異なる内容のものが定義されている状況は想定外なのではないかと思われます。見方を変えると、これらに関してプロジェクトの区別が無い、ということでもありますが、これは使う側の感覚としても想定外なのではないかという気がします。

    実際、以下のようにワークスペース内の別プロジェクトのソースを変更することで編集ウィンドウにエラーが表示されたり消えたりしてしまう症状が発生しています。試したプロジェクト一式を以下のzipファイルに固めてあります。(プロジェクトはワークスペースにインポートして下さい。) なお、ルネサス社のサンプルプログラムを丸ごと使っているのですが、そのソースは除外していますので、ルネサス社のダウンロードページからダウンロードしてソースをコピペして下さい。

    Issue_20170918.zip

    RX64Mグループ HMI拡張ボードを使ったカメラ機能/音声再生機能デモンストレーション RX Driver Package Application

    別プロジェクトのCソースで、その別プロジェクトのiodefine.hをインクルードすると、エラーが表示される



    別プロジェクトのCソースで、その別プロジェクトのiodefine.hをインクルードしなければ、エラーは表示されなくなる



    それで、この場合の対処法ですが、品種が異なるマイコンのプロジェクト(すなわちプロジェクト内のiodefine.hが異なるプロジェクト)を閉じておく、ということになるかと思います。

    別プロジェクトを閉じれば、エラーは表示されなくなる



    参考までに、試した時の画面コピーをもう少し追加しておきます。

    別プロジェクトのCソースで、その別プロジェクトのiodefine.hをインクルードした時







    別プロジェクトのCソースで、その別プロジェクトのiodefine.hをインクルードしなかった時







    別プロジェクトを閉じた時







  • NoMaYさん
    ほやです。

    色々と勉強になります。

    インデクサーについて若干補足します。

    インデクサーは、変数/関数/定数がどのファイルのどの行で定義されているかのデータベースを作成します。
    「インデクサー」→「再ビルド」のメニューはこのデータベースを再構築させるものです。

    CDT parserは「データベースにないもの」を未定義として警告表示などを行います。
    エディタの行やプロジェクトツリーに表示されるマーカーもエディタでソースコードを開いた時など、CDT parserが判定したタイミングで更新されます。
    インデクサー→再ビルドでも警告マーカーがすぐに消えないのはこのためです。「C/C++コード解析を実行」は強制的にCDT parserを実行させるのでマーカーも更新されます。

    インデクサーの設定を拡げれば確かにエラーや警告は解決されますが、エディタの動作やビルド開始時の処理が重くなるので、実際どこまで設定するかは必要に応じて決めれば良いのではないかと思います。
Reply
  • NoMaYさん
    ほやです。

    色々と勉強になります。

    インデクサーについて若干補足します。

    インデクサーは、変数/関数/定数がどのファイルのどの行で定義されているかのデータベースを作成します。
    「インデクサー」→「再ビルド」のメニューはこのデータベースを再構築させるものです。

    CDT parserは「データベースにないもの」を未定義として警告表示などを行います。
    エディタの行やプロジェクトツリーに表示されるマーカーもエディタでソースコードを開いた時など、CDT parserが判定したタイミングで更新されます。
    インデクサー→再ビルドでも警告マーカーがすぐに消えないのはこのためです。「C/C++コード解析を実行」は強制的にCDT parserを実行させるのでマーカーも更新されます。

    インデクサーの設定を拡げれば確かにエラーや警告は解決されますが、エディタの動作やビルド開始時の処理が重くなるので、実際どこまで設定するかは必要に応じて決めれば良いのではないかと思います。
Children
No Data