ラベル clang の投稿を表示しています。 すべての投稿を表示
ラベル clang の投稿を表示しています。 すべての投稿を表示

2020年12月22日火曜日

[C++] Clang ではオーバーロードされた private 関数に明示的な実体化時のアクセスができない?

※この記事は C++ Advent Calendar 2020 22日目の記事です。

はじめに

過去に本ブログでも紹介した template の明示的実体化時に private メンバーアクセス可能な仕様を利用した private メンバー変数・関数へのアクセスですが、最近それを使っていて clang だけとある条件でアクセスできないことに気づきました。

この挙動が仕様として正しいのか正しくないのかは筆者ではわからないので、実挙動ベースの話になってしまいますことをご了承ください。

過去の記事

ブログズミ: [C++] Private な関数のテスト
ブログズミ: [C++] 本当に private なところ

サンプルコード

こちらは iutest の private メンバーのテストのための機能を使ったサンプルです。
Wandbox 用に圧縮したソースコードを使ってますので、実装を確認したい場合はこちらを御覧ください。
https://github.com/srz-zumix/iutest/blob/master/include/iutest_prod.hpp#L62

#define IUTEST_USE_MAIN
#include "iutest.hpp"

class A
{
public:
    int GetX(void) { return m_x; }
private:
    int m_x;
};

IUTEST_MAKE_PEEP(int A::*, A, m_x);

IUTEST(Peep, Test1)
{
    A a;
    IUTEST_PEEP_GET(a, A, m_x) = 42;
    IUTEST_EXPECT_EQ(42, a.GetX());
    IUTEST_EXPECT_EQ(42, IUTEST_PEEP_GET(a, A, m_x));
}

IUTEST(Peep, Test2)
{
    A a;
    IUTEST_PEEP(A, m_x) x(&a);
    x = 54;
    IUTEST_EXPECT_EQ(54, a.GetX());
    x += x;
    IUTEST_EXPECT_EQ(108, a.GetX());
    IUTEST_EXPECT_EQ(108, x);
}

[Wandbox]三へ( へ՞ਊ ՞)へ ハッハッ
https://wandbox.org/permlink/2ZPvpUz1zDe1KHHs

ポイントは IUTEST_MAKE_PEEP と IUTEST_PEEP_GET です。
IUTEST_MAKE_PEEP で private メンバーアクセスするための情報をセットアップし、IUTEST_PEEP_GET で実インスタンスの private メンバーへの R/W を実現しています。

問題のコード
class Hoge
{
    int x;
public:
    Hoge() : x(42) {}
private:
    int GetX() { return x; }
    
private:
    int gX() { return x; }
    int gX() const { return x; }
    int gX(int) { return x; }
};


IUTEST_MAKE_PEEP(int (Hoge::*)(), Hoge, GetX);
IUTEST_MAKE_PEEP(int (Hoge::*)(), Hoge, gX);

int main()
{
    Hoge hoge;
    std::cout << IUTEST_PEEP_GET(hoge, Hoge, GetX)() << std::endl;
    std::cout << IUTEST_PEEP_GET(hoge, Hoge, gX)() << std::endl;
}

Clang の場合はエラー
https://wandbox.org/permlink/roGkNKKwsnaLX7og 
GCC の場合は OK
https://wandbox.org/permlink/AWd5A19WWDznccfq

エラーとなるのは gX 関数の PEEP で、オーバーロードされた関数があるとダメなようです。
Visual Studio はバージョンによって static メンバー関数がダメだったりするのは認識してましたが、 clang でもうまくいかないケースがあることがわかりました。

この挙動に関してなにか進展があったら、追記したいと思います。

では。


2020年11月26日木曜日

[C++] -Weverything で得たもの


こちらで紹介した C++ 警告のまとめプロジェクトの作成にあたって、自作テスティングフレームワークの iutest で clang のすべての警告を有効にするオプション「-Weverything」を使って得た知見をまとめます。

-Wdouble-promotion

double 型テストしてたつもりが float になってたのに気づきました。

-Wextra-semi

なぜか二重についてた ; セミコロンに気づきました。

-Wnonportable-system-include-path

Windows 系のヘッダーが全部小文字だったのを修正しました。

-Wshadow-all

マクロ内で使っていた変数名が b とか info とかかぶりやすい名前だったのを修正しました。

-Wdocumentation-unknown-command

こちらはワークアラウンドの紹介になりますが、 Clang は Doxygen のコメントに対しての警告がありますが、対応していない Doxygen コマンドが存在します。

Diagnostic flags in Clang — Clang 12 documentation

その場合、コンパイルオプションに -fcomment-block-commands=private,internal,retval のようにコマンドを教えてあげることができます。
ただし、引数のない private や internal コマンドは別の -Wdocumentation 警告がでるようになってしまいます。

../include/internal/iutest_time.hpp:47:13: error: empty paragraph passed to '@internal' command [-Werror,-Wdocumentation]
 * @internal
   ~~~~~~~~~^

こちらの回避方法はまだ見つけてないので、見つけたら追記します。

以上。


2020年7月15日水曜日

[Travis CI] Segmentation fault したときにスタックトレースを出力する設定

テストがクラッシュして失敗したときの調査が手間だなーということで対応しました。

対応したときの PR がこちらです。
差分で見ると、なにを追加したか見やすいと思います。
[Travis CI] core dump by srz-zumix · Pull Request #288 · srz-zumix/iutest

以下、ポイントを説明していきます。

導入

gdb のインストール


コアダンプファイルの出力設定


まず、コアダンプファイルが出力されるように ulimit の設定をします。
また、iutest ではテスト時に複数の実行ファイルを実行するため、コアダンプファイル名に実行ファイルの名前もつけるようにしています。
(コアダンプファイルの中身から取れる気もするけど、これで十分)

クラッシュしたらスタックトレースを出力する


実行ファイルの名前解決
linux - Core dump file name truncated - Stack Overflow
%e だと 15 文字で truncate されてしまい、実行ファイル名が正しく取れなかったので以下のような対応をしました。
gdb で coredump 開くと実行ファイルがなんだったのか出力されるので、それを取得してます。


      for f in `find . -maxdepth 1 -name "core_x_*"`; do
        COREFILE=${f}
        EXECFILE=${f##*/core_x_}
        if [ ! -f "${EXECFILE}" ]; then
          EXECFILE=`gdb -c "${COREFILE}" -batch | grep -o -e "\./[A-Za-z_]*"`
        fi
        gdb -c "${COREFILE}" ${EXECFILE} -ex "thread apply all bt" -ex "set pagination 0" -batch
      done


出力例




最後に
最近はローカル環境で実行確認することも減ってきたので CI 上でデバッグできるようにしておくのは便利でいいですね。

今回は以上です。
では。

2019年6月3日月曜日

lcov で "geninfo: ERROR: ***.gcno: reached unexpected end of file" が出たときにやったこと

Coveralls へのカバレッジレポートアップロードを Travis CI でやっていて、
今までは gcc + gcov でやっていたのだが、Codecov の方が clang から gcc に変更になったので、Coveralls は clang に。
と、思ったらぶつかったのでメモ。
https://github.com/srz-zumix/iutest/issues/234



まず、clang が生成する gcno のフォーマットが gcc 4.2 で、Travis CI の xenial 環境に入ってる gcc が 5.5 だったため clang + gcov でもエラーが出て集計できなかった、というのが根本的な原因と思われます。
gcov -r *.gcda;
also_run_disabled_tests.gcno:version '402*', prefer '505*'
Segmentation fault (core dumped)

この状態で lcov を使うと、表題のエラーになっていました。
geninfo: ERROR: /home/travis/build/srz-zumix/iutest/test/assertion_return_tests.gcno: reached unexpected end of file
lcov は gcov をバックエンドとして使っているので、おそらく内部的に gcov のエラーが置きているのではないかと予想。(ホントのところは知らんけど)

解決方法
Check Code Coverage with Clang and LCOV | Logan's Note

↑の記事にあるように、llvm-gcov.sh ファイルを作成する。中身は以下の通り


あとは、lcov のオプションに --gcov-tool path/to/dir/llvm-gcov.sh とするだけです。

iutest で実際にやってますので、そちらも参考にしてみてください。
ではでは。

2016年4月11日月曜日

[C++] Include-What-You-Use で依存関係を確認する

ブログズミ: [C/C++][Clang] include 解析ツールを作った
ちょっと前に clang で include 依存関係解析を書きましたが、最終的にやりたいことができるツールが既にあったので使ってみました。

Include-What-You-Use
ツールは Include-What-You-Use といいます。
こちらの存在は以下の記事を見て知りました。
Include-What-You-Use も clang の AST を利用して解析しているそうです。

ホームページのダウンロードリンクに Windows バイナリがあったので、今回はこれを使いました。
Downloads

また、使用方法は Github のドキュメントを参照。
How to Run
CXX を include-what-you-use にしてビルドすれば良いようです。

iutest で試した結果がこちら。
$ make CXX=include-what-you-use sample
include-what-you-use -I../../include -g -Wall -Wextra -Wundef    -c ../../samples/main.cpp
In file included from ../../samples/main.cpp:24:
In file included from ../../samples/../include/iutest.hpp:23:
In file included from ../../include/iutest_core.hpp:20:
In file included from ../../include/internal/iutest_result_reporter.hpp:20:
In file included from ../../include/internal/iutest_core_impl.hpp:20:
In file included from ../../include/internal/iutest_internal.hpp:20:
In file included from ../../include/internal/../iutest_pred.hpp:20:
In file included from ../../include/iutest_assertion.hpp:20:
In file included from ../../include/iutest_result.hpp:20:
In file included from ../../include/internal/iutest_message.hpp:20:
In file included from ../../include/internal/../iutest_env.hpp:20:
In file included from ../../include/internal/iutest_charcode.hpp:20:
In file included from ../../include/internal/iutest_port.hpp:24:
In file included from ../../include/internal/iutest_internal_defs.hpp:20:
In file included from ../../include/internal/../iutest_defs.hpp:20:
../../include/internal/iutest_compiler.hpp:38:12: fatal error: 'windows.h' file not found
#  include <windows.h>
           ^

../../samples/main.cpp should add these lines:
#include <vcruntime_new.h>                     // for operator new
#include "internal/../impl/../iutest_env.hpp"  // for Environment
#include "iutest_config.hpp"                   // for IUTEST_HAS_LIB
#include "util/iutest_util_output.hpp"         // for Console

../../samples/main.cpp should remove these lines:
- #include <iostream>  // lines 50-50

The full include-list for ../../samples/main.cpp:
#include <vcruntime_new.h>                     // for operator new
#include "../include/iutest.hpp"               // for AddGlobalTestEnvironment
#include "internal/../impl/../iutest_env.hpp"  // for Environment
#include "iutest_config.hpp"                   // for IUTEST_HAS_LIB
#include "util/iutest_util_output.hpp"         // for Console
---
Makefile:104: ターゲット 'main.o' のレシピで失敗しました
make: *** [main.o] エラー 7

Windows バイナリを使っているため、Windows sdk のパスを通さないといけません。
が、とりあえず sample.cpp に不要な iostream の include があるのがわかったので修正しました。

Visual Studio でできないか?
Visual Studio の拡張機能でないかなーと見ましたが、今現在はないもよう。
Clang for Windows があるし、このへんも対応してくれるとうれしいなーと思いました。
(※ なんとかできないか調査中)

2016/4/14 追記
include-what-you-use-cl を公開しました。
こちらは Visual Studio のプラットフォームツールセットとして、Include-What-You-Use を使えるようにするツールです。

git clone して install.bat を実行するとインストールされます。
別途、Include-What-You-Use.exe へのパスを通しておく必要があります。

インストールすると、プラットフォームツールセットに Include-What-You-Use の選択肢が出ます。

ビルドすると以下のように結果が出ます。


(※エラー出るかもしれませんが、依存関係の解析はできてるはず。)
(※なんでツールセットなのかは、ツールセットの定義の仕方の勉強がてらです。)

追記ここまで
==============

最後に
今回は、軽く触れる程度に Include-What-You-Use を紹介させていただきました。
では、また今度。


2016年2月2日火曜日

[C/C++][Clang] include 解析ツールを作った

無駄な include を消したいなーと思って、そのためにまずは解析できるようにならないと、と Clang を使ってやってみました。

ビルド環境構築
clang ソースのセットアップ
LLVM.org から LLVM と clang のソースをダウンロードします。
それぞれ展開をし、LLVM は任意のファルダに保存してください。

ここでは、 D:\usr\local\LLVM に置いたこととします。
clang は展開したフォルダを "clang" にリネームして、 D:\usr\local\LLVM\tools\clang に置きます。

clang のビルド
今回は Visual Studio 2015 向けにビルドします。
その前に CMake が必要になるので、インストールしておいて下さい。

コマンドプロンプトを開き、LLVM ソースフォルダに移動して、以下のコマンドを実行します。
LLVM> set path=%ProgramFiles(x86)%\CMake\bin
LLVM>mkdir build
LLVM>cd build
LLVM\build>cmake -G "Visual Studio 14" -D CMAKE_INSTALL_PREFIX=D:\LLVM ..

最初に path を書き換えているのは、cygwin のパスが通ってると CMake に失敗するためです。
CMAKE_INSTALL_PREFIX にはインストールフォルダを指定します。今回は D:\LLVM としています。
CMake が成功すると、LLVM.sln が出来上がってるのでビルドします。

ビルドができたら、INSTALL プロジェクトを選択してビルドします。
CMAKE_INSTALL_PREFIX に指定したところにインストールがされますので、これで完了です。

事始め
まずは、なにかサンプル的なものをビルド・実行できるようにするとイイと思います。
今回私は、以下のページを参考にしました。

include の解析
今回は #include の依存関係を知ることが目的です。
プリプロセスの追跡には PPCallbacksTracker を使うことになります。

そして include の依存関係から dot ファイルを作成するスゴク参考になりそうなものが clang/lib/Frontend/DependencyGraph.cpp にあります。
これを参考に書いたのがこちら。
https://github.com/srz-zumix/cincluder

システムファイルを除外したり、複数ファイルから include されているファイルに色付けするようにしています。
iutest を解析した結果がこちら。


コマンドラインオプション
cincluder を書いていて独自のコマンドラインオプションに対応したいなと思って調べたのでメモ。

static cl::OptionCategory CincluderCategory("cincluder");
static cl::opt< ::std::string > DotFile("dot", cl::init("cincluder.dot"), cl::desc("output dot file"), cl::cat(CincluderCategory));

cl::opt でオプションを定義します。
最初の文字列がオプション名で、あとは init で初期値、 desc で説明、 cat でカテゴリ情報を付与しています。
これらの設定には、cl::Positional とか、 cl::Required とかもあるみたいです。
他にどんな設定があるかは、 LLVM/include/llvm/Support/CommandLine.h を参照してください。

最後に
LibTooling 難しそうと思ってましたが使ってみたらそうでもなく、やりたいことがこんなにも簡単にできてしまうのかー、と驚きました。
「できる」というのが分かってしまえば気楽なもんで、お仕事とかでも気軽にツール作りができそうです。

2015年10月27日火曜日

[Coverity] CEDEC 2015 で出題されたバグクイズ

バグクイズです!(CEDEC 2015 の問題) « Coverity Blog

CEDEC 2015 で出題されたバグクイズ。
私も実際に CEDEC に行って見てきたわけですが、
3日目の問題が直ぐに解けず、なんだか悔しかったのでこの記事を書いてる次第です。
(あーだこーだしているうちに2ヶ月も経ってしまいましたが…)

ちなみに、答えはこちらです。
CEDEC 2015 Tokyo でのバグクイズの正解を発表! « Coverity Blog

Coverity 以外では検出できないのか?

検証の際に実際に使用したソースコードはこちら。
https://github.com/srz-zumix/coverity_test/tree/master/cedec_coverity

Cppcheck v1.70
まずは、フリーで使える C++ 静的解析の定番となっている Cppcheck です。
使用したのは現時点での最新バージョンである 1.7.0 です。

残念ながら、どちらの問題も検出されませんでした。

Visual Studio コード分析
次に Visual Studio です。
Visual Studio にはコード分析機能が付いています。プロジェクトプロパティのコード分析で有効にできます。

これもかなり優秀なんですが…


残念ながら、どちらの問題も検出されませんでした。

gcc/clang
最後はコンパイラーです。
Visual Studio はコード分析のときにビルドしましたが、検出できなかったので既に脱落しております。

それぞれの結果です。


どちらも delete (void*)p の問題は検出されました。

scan-build
おまけです。
scan-build は clang の静的解析ツールです。
cygwin パッケージに入ってたので使ってみました。


結果としては clang コンパイラーと一緒で delete (void*)p の検出だけでした。

まとめ
Coverity すごい!!


2014年9月16日火曜日

[LLVM 3.5] Clang for Windows

LLVM 3.5 がリリースされたので clang for windows を更新。
LLVM 3.4 では type_traits のエラーがあってビルドができませんでしたが、どうなったのか確認してみました。

対象プログラムは例のごとく iutest を使用しました。

※ LLVM 3.4 のときの対処は「ブログズミ: [LLVM 3.4] Clang for Windows を使ってみた」を参考にしてください。
※ clang for windows はこちらからダウンロードできます。

error : cannot compile this try statement yet
ostream(800,3): error : cannot compile this try statement yet
                  _TRY_IO_BEGIN
                  ^~~~~~~~~~~~~
ostream(19,24) :  note: expanded from macro '_TRY_IO_BEGIN'
   #define _TRY_IO_BEGIN  _TRY_BEGIN      /* begin try block */
                          ^
xstddef(30,21) :  note: expanded from macro '_TRY_BEGIN'
   #define _TRY_BEGIN     try {

try ステートメントでなぜかエラーが出ます。まだ対応していないようです。
[LLVMdev] Clang Integration with MSVS 2013
こちらを参考に /GR- /D_HAS_EXCEPTIONS=0 をコンパイルオプションに追加することで解決しました。
(/GR- :「ランタイム型情報を有効にする」を「いいえ」に設定)


error : expected class name
typeinfo(190,11): error : expected class name
          : public exception
                   ^
typeinfo(194,5): error : member initializer 'exception' does not name a non-static data member or base class
                  : exception(_Message)
exception クラスがないと怒られます。
エラー行を見るとわかりますが、_HAS_EXCEPTIONS=0 の場合でも bad_cast や bad_typeid などの例外クラスが定義されるようで、この例外クラスが exception クラスを基底クラスに持つのですが、なぜか exception ヘッダーがインクルードされていないため、エラーになっているようです。

よって、typeinfo をインクルードする前に exception ヘッダーをインクルードすることで解決しました。


error : array initializer must be an initializer list
assertion.cpp(191,17): error : array initializer must be an initializer list
          const char16_t c16[] = u"test";
                         ^
assertion.cpp(196,17): error : array initializer must be an initializer list
          const char32_t c32[] = U"test";
                         ^

char16_t/char32_t の配列初期化に初期化リストを要求されました。
重要な機能ではないので、char16_t/char32_t は非対応としてビルドするようにしました。


ビルド成功
上記対応をすることでビルドが通るようになりました!やりました。

実行もできます。


まだ対処しないといけない部分がありますが、動くものが作れるようになりました。
今回やったこと以外にも対処が必要だったり、問題があったりするかもしれませんが、Visual Studio で clang が扱えるようになるのはありがたいことです。今後にも期待したいと思います。

以上。


2014年1月22日水曜日

Windows で clang のビルド

Windows でも clang が使えるようにビルドしてみたので、個人用備忘録として残しておきます。
※ 完全に自分用の記事です。自分がした手順をまとめているだけです。
※ この手の情報は検索すればよく出てくるので、そちらを参考にしてもらったほうが良いです。

参照:
clang/LLVMをWindowsでビルドする - 原色奈良阪
LLVM を Windows で使う(clang 編) - 電脳スピーチ blog

準備したもの
MinGW
http://www.mingw.org/ からインストーラーをダウンロードしてセットアップ
※ 筆者環境は Windows 8 のためか、64bit 版の MinGW が必要になった。途中でダメなことに気づき 64bit 版のセットアップをしました。

CMake
cygwin の cmake は MinGW の Generator がなかったので、http://www.cmake.org/ から Windows インストーラーをダウンロードしてパスを通しました。

LLVM/clang
http://llvm.org/ のダウンロードページから LLVM source code と Clang source code をダウンロードし、
任意の場所に展開しました。
Clang は展開した後 clang にリネームして、llvm-3.3.src\tools に移動しました。


ビルド
パスを通す
MinGW のパスを環境変数に設定していないので、コマンドプロンプトを開いた後パスを通しました。
set path=C:\MinGW\bin;%PATH%
cmake
cmake のワーキングディレクトリとして、適当にフォルダを作成します。
今回は、build として作成しました。作成後、build ディレクトリに移動し cmake を実行します。
llvm-3.3.src>mkdir build
llvm-3.3.src>cd build
llvm-3.3.src>cmake -G "MinGW Makefiles" -D CMAKE_INSTALL_PREFIX=C:\usr\LLVM ..

libiconv-2.dll
cmake を実行したら libiconv-2.dll がないと言われて失敗してしまいました。
検索してもいまいちわからなかったので、msys の bin にあった msys-iconv-2.dll を C:\MinGW\bin にリネームしてコピーしました。
(今思えば コマンドプロンプトからではなく msys でやるべきだったのかも)

make
cmake が完了したら、build ディレクトリで make をします。
ビルドエラー
70% くらい進んだところでビルドエラーが発生
llvm-3.3.src\tools\clang\lib\Basic\FileManager.cpp:317:73: err
or: no matching function for call to 'clang::FileManager::getStatValue(const cha
r*&, _stat64i32&, bool, int)'
   if (getStatValue(InterndDirName, StatBuf, false, 0/*directory lookup*/)) {
検索したところ以下のサイトがヒットしました。
http://comments.gmane.org/gmane.comp.compilers.clang.devel/32242
そこから以下のサイトを参考にしたら解決したとのことなので、私も参考にしました。
https://github.com/KhronosGroup/webcl-validator#building-with-windows-mingw--msys
これによると、64bit 版の MinGW を使えってことのようです。
早速、MinGW 64bit 版をダウンロード、セットアップし、同様にビルドしました。
MinGW 64bit 版のセットアップはこちらを参考にしました。
PENGUINITIS - MinGW 64 bit 版 のセットアップ

ビルド(MinGW 64bit)
MinGW 64bit 版をセットアップし、 cmake からやり直しました。
(make.exe がなかったので mingw32-make.exe をコピー・リネームしました。)

これで無事ビルド完了。

最後に make install をします。
CMAKE_INSTALL_PREFIX で指定したパスにインストールされます。

Visual Studio でビルド
そもそもの目的が libclang 使ったツールを作ることだったので、Visual Studio でビルドしました。

LLVM と clang のソースを取得するとこまでは一緒で、cmake するときの -G オプションを "Visual Studio 10" にします。
cmake が無事に終わると Visual Studio のプロジェクト/ソリューションが出来上がるので、それを Visual Studio で開いてビルドするだけです。

特に問題なくビルドできました。
これで libclang が使えます。

Clang for Windows
先日リリースされた Clang for Windows には libclang が付いているので、libclang が使いたいだけならこれをインストールするだけで OK でした。。。

まぁ、ともあれ。
libclang のことは知らないことだらけなので、これから少しずつやっていこうかと思います。

2014年1月20日月曜日

[LLVM 3.4] Clang for Windows を使ってみた

clang 3.4 から Visual Sutdio 向けのツールセットが使えるようになりました。
これに関しては二、三番煎じもいいとこなので、説明を省きます。
Happy my life » Clang 3.4をVisualStudioから利用する

さて、早速 clang for windows をインストールして使ってみたのですが、
警告やらエラーだらけでビルドできませんでした。

その辺の解決方法を記しておきます。

warning : argument unused during compilation
warning : argument unused during compilation: '/Gm'

まず、コンパイラオプションに対して警告が出ます。
こちらは公式ドキュメントにも書いてあるとおりに、"-Qunused-arguments" オプションをつけると無視されます。

type_traits
type_traits ヘッダーでエラー
error : '_Ty' does not refer to a value
error : expected class name
__is_constructible などの builtin 機能がないためエラーになっているようです。
バグ報告もされています。
Bug 17926 – clang-cl: error compiling VC++12 type_traits header

type_traits ヘッダーは vector や tuple などから include されているので、単純に type_traits を include しないだけでは回避できませんでした。
ちょっと回避策もないので、次バージョンまで待とうと思います。。。

2013年11月5日火曜日

ClangOnWin を使ってみた

clang を Windows でも簡単に使いたいと思い、ビルド済みのものを探していたら
「ClangOnWin」というものを見つけたので試してみました。

インストール
ClangOnWin のページからインストーラーがダウンロードできますので、
そちらを取得したらインストーラーを起動します。(※ この記事では LLVM-3.4.svn-win32-2013.11.01-193854.exe を使用しました)


起動したら特に変更なくデフォルト設定のままインストールをします。

ツールセット
インストールが完了すると Visual Studio のプラットフォームツールセットに LLVM が追加されます。


これを LLVM-vs2013(2010,2012) にすることで clang でのビルドができます。

ビルドしてみる
早速ビルドしてみると大量に警告がでます。

Visual Studio のコンパイラオプションがないため警告が出ているだけなので、
気にすることはないですが、うるさいのでプロジェクトの修正をしました。(メンドクサイ…)

コンパイルオプションの警告を取り除きましたが、まだ警告が・・・

今回試しにビルドしているプロジェクトでは _s 系の関数は使わず pragma で警告を抑止しているため上記のような警告が出てしまった。
今後も _s に書き換える方針はないので、今回も警告を抑止した。(pragma は使えないので _CRT_SECURE_NO_WARNINGS を define しました)
実際、この辺みんなどうしているのだろうか?

ビルドエラー
LLVM-vs2013 でビルドしたのですが、 type_traits でエラーが出てしまいました。


LLVM-vs2012 でもエラーが…


error: cannot mangle RTTI descriptors for type 'codecvt' yet
ちょっとお手上げです…
もうしばらく弄ってはみるので、何かわかったらここで報告します。
(解決策も募集!)

追記 11/5
もう少し調べてみたら ClangOnWin のファイルリストのページに説明が書いてありました。
それによると、RTTI は使えないようです。また、-D_HAS_EXCEPTIONS=0 も必要なようです。
RTTI を無効にするには、「プロジェクト」 - 「プロパティ」からプロパティダイアログを開き、「C/C++」 - 「言語」 - 「ランタイム型情報を有効にする」 を 「いいえ(/GR-)」 に設定します。

これで、ビルドが通るかと思ったのですが、まだダメでした。。。残念
error : cannot mangle the name of type 'basic_streambuf' into RTTI descriptors yet