[llvm-bugs] [Bug 24790] New: clang's -ast-dump segfaults on objc_bridge_related attribute with missing optional argument

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=24790

            Bug ID: 24790
           Summary: clang's -ast-dump segfaults on objc_bridge_related
                    attribute with missing optional argument
           Product: clang
           Version: 3.6
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: GW at neurosynthase.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

I encountered this using the -ast-dump feature of Apple's clang 6.1.0, and get
the following behavior:

pythagoras:dev gwashington$
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-cc1 -E -v -ast-dump -x objective-c <(echo "typedef struct
__attribute__((objc_bridge_related(NSColor,,))) CGColor *CGColorRef;")
clang -cc1 version 6.1.0 based upon LLVM 3.6.0svn default target
x86_64-apple-darwin14.5.0
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0/include

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
TranslationUnitDecl 0x10302d4c0 <<invalid sloc>> <invalid sloc>
|-TypedefDecl 0x10302d9c0 <<invalid sloc>> <invalid sloc> implicit __int128_t
'__int128'
|-TypedefDecl 0x10302da20 <<invalid sloc>> <invalid sloc> implicit __uint128_t
'unsigned __int128'
|-TypedefDecl 0x10302dab0 <<invalid sloc>> <invalid sloc> implicit SEL 'SEL *'
|-TypedefDecl 0x10302db80 <<invalid sloc>> <invalid sloc> implicit id 'id'
|-TypedefDecl 0x10302dc50 <<invalid sloc>> <invalid sloc> implicit Class
'Class'
|-ObjCInterfaceDecl 0x10302dca0 <<invalid sloc>> <invalid sloc> implicit
Protocol
|-TypedefDecl 0x10302e040 <<invalid sloc>> <invalid sloc> implicit
__builtin_va_list '__va_list_tag [1]'
|-RecordDecl 0x10302e0a0 </dev/fd/63:1:9, col:64> col:64 struct CGColor
| `-ObjCBridgeRelatedAttr 0x10302e140 <col:31, col:60> NSColor Stack dump:
0.                        Program arguments:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-cc1 -E -v -ast-dump -x objective-c /dev/fd/63
1.                        <eof> parser at end of file
Segmentation fault: 11

I believe the problem stems from ObjCBridgeRelatedAttr using null pointers if
its optional arguments aren't given, as in

clang/lib/Parse/ParseDecl.cpp:1068:
    IdentifierLoc *ClassMethod = nullptr;

ASTDumper dumps the arguments of the attribute ultimately using code generated
by EmitClangAttrDump, specifically with a call to

clang/utils/TableGen/ClangAttrEmitter.cpp:2770:
    for (const auto *Arg : Args)
        createArgument(*Arg, R.getName())->writeDump(OS);

which evaluates to

clang/utils/TableGen/ClangAttrEmitter.cpp:273:
    void writeDump(raw_ostream &OS) const override {
    ... (4 lines omitted)
        OS << "    OS << \" \" << SA->get" << getUpperName()
           << "()->getName();\n";

I believe the ->getName() call generated above is what dereferences the
nullptr, causing the segfault. I haven't built clang at master myself to verify
any of this, so I apologize in advance if my analysis is flawed.

I encountered this while attempting to get an AST dump for the latest
CoreText/CTParagraphStyle.h in the iOS 9 sdk if any apple folk care :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150911/381a0a73/attachment.html>