<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 24, 2014 at 2:30 PM, Nikola Smiljanic <span dir="ltr"><<a href="mailto:popizdeh@gmail.com" target="_blank">popizdeh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div class="gmail_extra"><div class="gmail_quote"><span class="">On Tue, Nov 25, 2014 at 8:59 AM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.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="ltr">If Clang is configured without x86 backend support, there will be linker errors here. I believe we have a wrapper called InitializeAllRegisteredTargets() and some cmake way to link in all target libraries. We could just do that.</div></blockquote><div><br></div></span><div>Yeah, I saw those functions but they seemed like an overkill. This is only needed for x86 as Microsoft doesn't allow inline assembly on x64. Plus I didn't want to spend two hours figuring out what libraries to link against. I'm OK with initializing all targets if that makes sense? Any ideas where I can find that cmake magic?</div><span class=""><div><br></div><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="ltr"><div>It might also be better to make it so that tools can easily recover with a partial AST in this situation. They won't be able to see if the inline asm blob uses any parameters so any refactorings could possibly be broken, but that was already the case for clang-modernize.</div></div></blockquote><div><br></div></span><div>I don't follow :) </div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">Your proposed fix only works for clang-modernize, but not clang-tidy or libclang clients. I'm saying it'd be nice if we could make it easy for tools to recover from this error instead of trying to fix it by pulling in the whole LLVM x86 backend. None of these tools should attempt to refactor system headers, for example, so ignoring functions with __asm blocks is probably good enough.</div></div>