こんにちは、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_audioFile: file:/C:/Renesas/RX/issue_20170918/workspace_e2v600/rx64m_rsk_audio/r_bsp/board/rskrx64m/resetprg.cLanguage: GNU CIndex Version: 206.0Build Configuration: HardwareDebugContext: 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\incMacro 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=1Macro 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 ## xMacro 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
ルネサス社の日本向けのFAQや海外向けのKnowledgebaseには、インデクサー(INDEXER)とコード解析(CODAN)に関するものとして、以下のものがありました。(日本向けも海外向けも内容は同じでした。)FAQFAQ 1011331 : エディタ画面上に表示される虫のアイコンは何でしょう？FAQ 1011382 : 「型'****'が解決できません」のコード解析エラーを回避する方法FAQ 1011212 : コード解析のエラーを表示しないようにしたい。KnowledgebaseWhat are the bug icons shown in Editor view?How to suppress "Type '***' could not be resolved" code analysis error?I want to hide the static code analysis (CODAN) warnings.[関連リンク]統合開発環境(e² studio) - Renesas FAQe2 studio - Renesas Knowledgebase
Rulzには、インデクサー(INDEXER)とコード解析(CODAN)に関するスレッドとして、以下のものがありました。日本語情報e2_studioのプリプロセッサ機能についてFITモジュールでコンパイルエラー英語情報E2Studio has issues with semantic errorsFields not resolved, but will compile successfully[関連リンク]Rulz(かふぇルネ)検索: e2studioRulz(本家)フォーラム: e2studio
e2 studio v6.0.0(というかEclipse/CDTも?)のヘルプはReferenceの内容とWhat's new in CDTの内容が異なっており、しかも共に実際のものと異なっていて、何だか良く分かりません、、、Referenceの内容What's new in CDTの内容なお、ワークスペースの設定の すべてのファイルに索引付け(ビルトもインクルードもなし) (英語表記 Index source files not included in the build) や 未使用のヘッダーを索引付け (英語表記 Index unused headers) に関しては以下の情報が参考になりそうです。www.google.co.jp/search?q="Index+source+files+not+included+in+the+build"+site:eclipse.orgbugs.eclipse.org/bugs/show_bug.cgi?id=274777www.google.co.jp/search?q="Index+unused+headers"+site:eclipse.orgbugs.eclipse.org/bugs/show_bug.cgi?id=377992また、ワークスペースの設定の Allow heuristic resolution of includes に関しては以下のページの情報が参考になりそうです。wiki.eclipse.org/CDT/User/NewIn60#Indexing[関連リンク]e2 studio v6.0.0 リリースノートEclipse Neon CDT オンラインヘルプWhat's new and noteworthy in CDT
ワークスペースの設定では Index all header variants を 有効 にしておいた方が良さそうです。というのは、別スレッドで以下のように書いたのですが、どうもこの設定により、ヘッダファイルの実質的な内容が微妙に変わる、ということに対処するかどうか切り替えることが出来るようです。(恐らく設定を切り替える場合のトレードオフは操作の軽さ/重さになるのではないかと思います。)「昔を思い出していた時に記憶が甦って来たのですが、この手の誤動作はe2 studio(というかEclipse/CDT)の実装が以下のようになっているからでは無いだろうかと仮説を立てて調べようとしていたことがありました。(当時は確信には至りませんでした。) この後、昔を思い出して、少し調べてみます。・一度解析したヘッダファイルの解析結果はキャッシュされているのでは？・そして同名のヘッダファイルに遭遇したらキャッシュの内容が使用されるのでは？・ところがヘッダファイルの名前しか管理していないので以下の状況で混乱が起きるのでは？(1) 異なるパスに同名で内容の異なるヘッダファイルがある(2) ファイルがインクルードされる順番に依存してヘッダファイルの実質的な内容が微妙に変わる(3) 同一プロジェクトでもcppファイルにインクルードされる時とcファイルにインクルードされる時がある(4) ワークスペースにデファイン定義のコンパイルオプションが異なる複数のプロジェクトがある・キャッシュされた内容は何らかのタイミングで破棄されるものである(それがキャッシュというもの)・このことと上に書いた混乱が組み合わさると以下のようなことまで起きるかも知れない？(5) 別のファイルを編集しているうちにエラーが現れたり消えたりすることがある？(6) 編集ウィンドウでファイルを閉じて開くだけでもエラーが現れたり消えたりすることがある？とか、、、」実際、ちょっと作為的なソースですが、以下のソースで試してみると、編集ウィンドウにエラーが表示されるかどうかが変わることが確認出来ました。(ビルドはエラー無く完了する。) なお、試したプロジェクト一式を以下のzipファイルに固めてあります。(次の投稿で試したプロジェクト一式も含んでいます。プロジェクトはワークスペースにインポートして下さい。)Issue_20170916.zipTest1.h
#ifndef TEST1_H_#define TEST1_H_#ifdef TEST1A#define TEST1AA 1#endif#ifdef TEST1B#define TEST1BB 1#endif#endif /* TEST1_H_ */
Test1a.c
#define TEST1A#include "Test1.h"void funcA(void);int testA;void funcA(void){ testA = TEST1AA;}
Test1b.c
#define TEST1B#include "Test1.h"void funcB(void);int testB;void funcB(void){ testB = TEST1BB;}
Index all header variantsが無効(デフォルト)のままだと編集ウィンドウにエラーが表示されるIndex all header variantsを有効にしておくと編集ウィンドウにエラーは表示されなくなる参考までに、試した時の画面コピーをもう少し追加しておきます。Index all header variantsが無効(デフォルト)のままの時Index all header variantsを有効にしておいた時なお、以下の画面コピーのように右ボタンメニューで、適宜、[インデックス]→[再ビルド]を行ったり[C/C++コード解析を実行]を行ったりしました。
前の投稿で、ワークスペースの設定では Index all header variants を 有効 にしておいた方が良さそうです、とは書いたのですが、更に以下のソース(これもちょっと作為的なソースですが)で試してみると、残念ながら全てが解決する訳ではありませんでした。しかも、編集ウィンドウにエラーが表示されたまま消えないという単純な話では無く、編集ウィンドウに表示されるエラーが変化してしまうという厄介な話になってしまいました。なお、試したプロジェクト一式は前の投稿のzipファイルに含まれています。Test2.h
#ifndef TEST2_H_#define TEST2_H_#ifdef TEST2A// Adapted from iodefine.h of RX64Mstruct st_system { union { unsigned char BYTE; struct { unsigned char :1; unsigned char MOSEL:1; unsigned char MODRV2:2; unsigned char :3; unsigned char MOFXIN:1; } BIT; } MOFCR;};#define SYSTEM (*(volatile struct st_system *)0x80000)#endif /* #ifdef TEST2A */#ifdef TEST2B// Adapted from iodefine.h of RX63N,RX631struct st_system { union { unsigned char BYTE; struct { unsigned char :7; unsigned char MOFXIN:1; } BIT; } MOFCR; union { unsigned char BYTE; struct { unsigned char :3; unsigned char PSTS:5; } BIT; } PLLWTCR;};#define SYSTEM (*(volatile struct st_system *)0x80000)#endif /* #ifdef TEST2B */#endif /* TEST2_H_ */
Test2a.c
#define TEST2A#include "Test2.h"void funcA(void);void funcA(void){ SYSTEM.MOFCR.BIT.MOSEL = 1; //SYSTEM.PLLWTCR.BYTE = 0x0D;}
Test2b.c
#define TEST2B#include "Test2.h"void funcB(void);void funcB(void){ //SYSTEM.MOFCR.BIT.MOSEL = 1; SYSTEM.PLLWTCR.BYTE = 0x0D;}
Index all header variantsが無効(デフォルト)のままの時はTest2b.cでエラーが表示されるIndex all header variantsを有効にしておいた時はTest2a.cでエラーが表示される参考までに、試した時の画面コピーをもう少し追加しておきます。Index all header variantsが無効(デフォルト)のままの時Index all header variantsを有効にしておいた時
前の投稿では、ちょっと作為的なソースで試したのですが、同じような症状は、ワークスペース内に品種が異なるマイコンのプロジェクトを混在させた場合にも発生してしまうようです。(というか、最初にそのことに気付いた後、もっと簡単なプロジェクトでも同じような症状が発生することを確認してみた、というのが実際の順序でした。)たぶん、ワークスペースの設定でIndex all header variantsを有効にしても、その設定の対象となるものはマクロ定義のみで、構造体や共用体、或いは列挙体やtypedefとか、更にはC++のクラスなど、といったものは対象外なのではないかと思われます。つまり、これらに関しては、ワークスペース内に同じ名前で異なる内容のものが定義されている状況は想定外なのではないかと思われます。見方を変えると、これらに関してプロジェクトの区別が無い、ということでもありますが、これは使う側の感覚としても想定外なのではないかという気がします。実際、以下のようにワークスペース内の別プロジェクトのソースを変更することで編集ウィンドウにエラーが表示されたり消えたりしてしまう症状が発生しています。試したプロジェクト一式を以下のzipファイルに固めてあります。(プロジェクトはワークスペースにインポートして下さい。) なお、ルネサス社のサンプルプログラムを丸ごと使っているのですが、そのソースは除外していますので、ルネサス社のダウンロードページからダウンロードしてソースをコピペして下さい。Issue_20170918.zipRX64Mグループ HMI拡張ボードを使ったカメラ機能/音声再生機能デモンストレーション RX Driver Package Application別プロジェクトのCソースで、その別プロジェクトのiodefine.hをインクルードすると、エラーが表示される別プロジェクトのCソースで、その別プロジェクトのiodefine.hをインクルードしなければ、エラーは表示されなくなるそれで、この場合の対処法ですが、品種が異なるマイコンのプロジェクト(すなわちプロジェクト内のiodefine.hが異なるプロジェクト)を閉じておく、ということになるかと思います。別プロジェクトを閉じれば、エラーは表示されなくなる参考までに、試した時の画面コピーをもう少し追加しておきます。別プロジェクトのCソースで、その別プロジェクトのiodefine.hをインクルードした時別プロジェクトのCソースで、その別プロジェクトのiodefine.hをインクルードしなかった時別プロジェクトを閉じた時
こんにちは、NoMaYです。ほやさん、フォロー有難う御座います。唐突ですが、ここまでの内容を象徴するような(つまり厳密ではない)何か印象に残る例え話はないかと考えていて1つ思い付きました。映画や漫画で、大事な物を入れたカバンを持った主人公と、そのカバンと同じ色と柄のカバンを持った面識の無い人物が、廊下の曲がり角でぶつかって転んだ拍子にお互いのカバンを取り違えてしまい、いざ主人公がカバンの中からそれを取り出そうとすると、入っている筈の物が無くて困った事態になる、というストーリー展開がありますよね。ここまでの内容は、インデクサーが探索する範囲が狭いとか探索する場所が違うとか、そういった感じではなくて、むしろこんなような感じのことになるのかなぁ、と思いました、、、[追記]面識の無い人物という人物設定の他に、親子だったり、兄弟姉妹だったり、あるいは恋心を抱いている異性だったり、色々なバリエーションがありますね。あと、カバン以外に、同じロゴが印刷された封筒だったり、同じ包装のプレゼントだったり、とかもありますね。
NoMaYさん
ほやです。
CDT プラグインは9.2なのにヘルプが8.3になっている件がまだ気になっていたので、Eclipse本家の情報を確認してみました。
Eclipse/Neon(CDT9.x対応のはず)のオンラインヘルプを見ると8.3のままでした。http://help.eclipse.org/neon/topic/org.eclipse.cdt.doc.user/concepts/cdt_c_whatsnew.htm?cp=8_5
Eclipse本家からCDT(cdt-9.2.1.zip)をダウンロードして中を見てみましたが、そちらでも8.3のヘルプしか入っていませんでした。http://www.eclipse.org/cdt/downloads.php
本家のマニュアルがそもそも間に合っていないので、これはどうしようもなさそうです。困るなぁ、そういうの。