VSCode上での#pragma packエラーを黙らせる良い方法は?

最近CS+のコード編集環境を秀丸からVSCodeへ乗り換えて__evenaccess問題など解決できましたが通信データ構造の記述等で

#pragma pack

を使うコードがありコンパイルは問題無くできるものの表示上のエラーが出てうっとうしいので黙らせたいのですが

#ifndef _VSCODE

    #pragma pack

#endif

と修正せずにVSCode側の設定でスマートな黙らせ方はあるでしょうか?

  • LunaJamさん、こんにちは。NoMaYと申します。

    VSCode側の設定では無いのですが、最近のRXスマートコンフィグレータで生成したソース(というかRX Driver PackageのFITのR_BSPモジュール)では、r_rx_compiler.hというソースがあって、以下の記述になっています。この記述をコピペして、VSCodeのIntellisence対応の条件コンパイル文を追加して、利用するようにしてはどうでしょうか?(ちなみに、私はひとつテーマを見付けました。やるとは明言出来ないですけど、r_rx_compiler.h全体をIntellisence対応にする(といってもVSCode上でのエラー表示を抑止するだけですが)、というものです。その後、単体RXスマートコンフィグレータでCC-RX向けコードが生成出来るように成らないものかとRenesasさんに働き掛けて行ってみる、、、[訂正]すみません、勘違いしました。単体RXスマートコンフィグレータでコード生成出来ないのは、GNURXでした。CC-RX(とICCRX)は出来るのでした。)

    FITでコンパイラの#pragma pack等の仕様の違いを吸収している箇所
    github.com/renesas-rx/rx-driver-package/blob/49fc7a9/source/r_bsp/r_bsp_vx.xx/r_bsp/mcu/all/r_rx_compiler.h#L1555

    /* ---------- Alignment Value Specification for Structure Members and Class Members ---------- */
    #if defined(__CCRX__)

    #define R_BSP_PRAGMA_PACK          R_BSP_PRAGMA(pack)
    #define R_BSP_PRAGMA_UNPACK        R_BSP_PRAGMA(unpack)
    #define R_BSP_PRAGMA_PACKOPTION    R_BSP_PRAGMA(packoption)

    #elif defined(__GNUC__)

    #define R_BSP_PRAGMA_PACK          R_BSP_PRAGMA(pack(1))
    #define R_BSP_PRAGMA_UNPACK        R_BSP_PRAGMA(pack(4))
    #define R_BSP_PRAGMA_PACKOPTION    R_BSP_PRAGMA(pack())

    #elif defined(__ICCRX__)

    #define R_BSP_PRAGMA_PACK          R_BSP_PRAGMA(pack(1))
    #define R_BSP_PRAGMA_UNPACK        R_BSP_PRAGMA(pack(4))
    #define R_BSP_PRAGMA_PACKOPTION    R_BSP_PRAGMA(pack())

    #endif

    作業案1) R_BSP_PRAGMA()側でIntellisence時のR_BSP_PRAGMA()を無効にする(以下のCC-RXのC++モードと同様な感じかと思う)
    github.com/renesas-rx/rx-driver-package/blob/49fc7a9/source/r_bsp/r_bsp_vx.xx/r_bsp/mcu/all/r_rx_compiler.h#L158

    /* ========== Keywords ========== */
    #if !(defined(__CCRX__) && defined(__cplusplus))
    #define R_BSP_PRAGMA(...)    _Pragma(#__VA_ARGS__)
    #else
    /* CC-RX' C++ mode does not support Pragma operator and variadic macros */
    #define R_BSP_PRAGMA(x)
    #endif

    作業案2) R_BSP_PRAGMA_PACK()等側でIntellisence時のR_BSP_PRAGMA_PACK()等を無効にする(例えば以下のe2 studio/EclipseのINDEXER対応のように)
    github.com/renesas-rx/rx-driver-package/blob/49fc7a9/source/r_bsp/r_bsp_vx.xx/r_bsp/mcu/all/r_rx_compiler.h#L608

    /* ---------- Inline Expansion of Assembly-Language Function (part2) ---------- */
    #if defined(__CDT_PARSER__)

    #define R_BSP_ASM(...)            /* none */
    #define R_BSP_ASM_LAB_NEXT(n)     /* none */
    #define R_BSP_ASM_LAB_PREV(n)     /* none */
    #define R_BSP_ASM_LAB(n_colon)    /* none */
    #define R_BSP_ASM_BEGIN           /* none */
    #define R_BSP_ASM_END             /* none */

    #else

    #if defined(__CCRX__)

    #if !defined(__cplusplus)
    #define R_BSP_ASM(...)            __VA_ARGS__
    #else
    /* CC-RX' C++ mode does not support variadic macros */
    #endif
    #define R_BSP_ASM_LAB_NEXT(n)     ?+
    #define R_BSP_ASM_LAB_PREV(n)     ?-
    #define R_BSP_ASM_LAB(n_colon)    R_BSP_ASM(?:)
    #define R_BSP_ASM_BEGIN           /* none */
    #define R_BSP_ASM_END             /* none */

    #elif defined(__GNUC__)



    #elif defined(__ICCRX__)



    #endif

    #endif /* defined(__CDT_PARSER__) */

    [関連リンク]

    CC-RXもGNURXもC99仕様では_Pragmaプリプロセッサ演算子というものが使えるのですね(FITのコンパイラ対応の効率化に役立ちそうかも)
    japan.renesasrulz.com/cafe_rene/f/forum5/5079/cc-rx-gnurx-c99-_pragma-fit
     

  • NoMaY様、提案有り難う御座います。

    結局何らかの形でソースコードに手を入れないと無理なんですね。
    基本的にドライバ類はほぼ自作でFITは使ってないのも同然なので
    #if defined(__CCRX__)
    で誤魔化そうかと思います。
    インラインアセンブラ部はかっこわるいですが滅多に使わないので諦めます。
  • LunaJamさん、こんにちは。NoMaYです。

    MSC(今もコンパイラ自体の呼び方はMSCで良いのか最近は疎くなってしまいましたが)にもCC-RXにも#pragma packというプラグマがあるけれど両者でその後に続く文字列に互換性が無かった、ということがVSCODEが文句を言ってくる原因でしょうね。ですので、最終的には#ifdef~#endifに落とし込まざるを得ないのかな、と考えたのでした。

    ただ、その際に、その#ifdef~#endifをソースの各所にちりばめるよりもFITで取られているようなやり方でC99のプラグマ演算子を使えばソースの見た目がすっきりするかな、と考えたのです。で、LunaJamさんのソースでFITをガチガチに使っているかどうか余り重きに無くて、そういうやり方を真似る際にFITのコードの一部をコピペしてしまうのが一番手っ取り早いかな、と考えたのでした。

    ちなみに、__evenaccessでVSCODEが文句を言ってきただろうと思いますが、LunaJamさんが採られた方法は以下のように、ヘッダファイルの1つに以下の#defineを入れるような感じですよね?

    #ifdef _VSCODE

        #define __evenaccess /* nothing to be defined */

    #endif

     

  • LunaJamさん、こんにちは。

    古い投稿への返信ですが、#ifdef以外に以下の方法もあります。

    1.
    #pragma diag_suppress 661

    ※今回のpackの警告が661番なので

    これだけでもよいですが、
    適当なヘッダファイルを作成して上記pragmaを記述、以下の設定に追加する
    (このヘッダはVSCodeのときだけインクルードする)

    C/C++拡張(ms-vscode.cpptools)の設定
    コマンドパレット(Ctrl+Shift+P)から、C/C++: Edit Configuration (UI)
    詳細設定の中の、強制インクルード

    追加のヘッダが気持ち悪いかもしれませんが、元のソースを汚さずに対処できます。

    警告661についてググっても情報が出てこないので、どこまで抑制されるかはわかりませんが、今回のようなpragmaだけかなと予想はしています。

    2.
    ツールチップのQuick Fix...→エラーの波線を無効にする
    または、

    .vscode\settings.json
    {
    "C_Cpp.errorSquiggles": "Disabled"
    }

    手っ取り早いですが、こちらは上記pragma以外の波線も出なくなってしまいます。
    それでもよければ。

    【補足】
    C/C++: Edit Configuration (UI)
    で、コンパイラパスという設定もありますが、ここでCCRLのパスを設定しても解決しません。
    コンパイラ固有のパスや定義はケアしてくれるみたいですが、pragmaは対応していないようです。

    未定義のpragmaは無視される(通常は問題にならない)ので、今回のpackのようなケースは非常にレアだからなのかなと思います。