Handle MS-style inline assembly in clang-modernize

[Nikola Smiljanic]

I spent an hour on this today, and returning an StmtEmpty
from ParseMicrosoftAsmStatement seems to work just fine. Note that parsing
happens in two phases, asm line collection and actual MC stuff and I bail
out right after first phase ends. Does this make sense and if so what
should be the condition to check?. I guess we need something that doesn't
exist right now, like IsTooling? We could use
SourceManager::isInSystemHeader(AsmLoc) in addition, tools would still
error out if client code uses inline asm, but at least it wouldn't allow
the tool to break anything.

On Tue, Nov 25, 2014 at 3:43 PM, Kim Gräsman <kim.grasman at gmail.com> wrote:

> On Mon, Nov 24, 2014 at 11:41 PM, Reid Kleckner <rnk at google.com> wrote:
> >
> > 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.
>
> Topical:
> http://clang-developers.42468.n3.nabble.com/libclang-crash-when-parsing-MS-style-inline-assembly-td4035432.html#a4035754
>
> I never got around to checking if LLVMInitialize* do fail silently in
> the absence of X86 target support, so I can't tell what happens there.
> Actual asm parsing seems to be short-circuited if target info is not
> available.
>
> - Kim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141205/36aec6cf/attachment.html>