<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 15, 2015 at 1:55 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div><br><br>Sent from my iPhone</div><span class=""><div><br>On Dec 15, 2015, at 11:50 AM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I think I fixed that const qualified issue with r255678. I still have warnings from ppltasks.h, which is this connect issue:<div><a href="https://connect.microsoft.com/VisualStudio/feedback/details/1132688/ppltasks-h-does-not-compile-cleanly" target="_blank">https://connect.microsoft.com/VisualStudio/feedback/details/1132688/ppltasks-h-does-not-compile-cleanly</a><br></div><div><br></div><div>I think we should ban inclusions of <future> in LLVM and make a wrapper header that uses pragmas to disable warnings in <future> transitive includes.</div></div></div></blockquote><div><br></div></span><div>#include "llvm/Support/future.h"?</div><div>I can give a try at that later today, but since I can't validate with MSVC it might take a few tentatives, so I don't mind if someone else do it.</div></div></blockquote><div><br></div><div>I'm actually inclined to throw them all in "llvm/Support/thread.h", since we're probably going to need more ifdefs to avoid these includes when !LLVM_ENABLE_THREADS.</div><div><br></div><div>Have you considered how ThreadPool should operate when the STL does not provide C++11 threading headers? We told users in that situation to turn off LLVM_ENABLE_THREADS, but this would de-support such a configuration altogether.</div></div></div></div>