search for: dimacro

...leIncludeDecl" AST might contain other "FileIncludeDecl"/"MacroDecl" ASTs. These two new AST DECLs are not part of TranslationUnitDecl and are handled separately (see AST example below). In the LLVM IR, metadata debug info will be extended to support new DIs as well: "DIMacro", "DIFileInclude", and "MacroNode". The last, is needed as we cannot use DINode as a base class of "DIMacro" and DIFileInclude" nodes. DIMacro will contain: * type (definition/undefinition). * line number (interger). * name (null termina...

...that class. The only drawback with this approach, is that we can test the frontend using the generated LLVM IR, i.e. the whole path, instead of having two tests, AST for testing the parser, and LLVM IR for testing the Sema. > I wonder if it'd be better to use a parent chain style approach (DIMacro has a DIMacroFile it refers to, each DIMacroFile has another one that it refers to, up to null)? > (does it ever make sense/need to have a DIMacroFile without any macros in it? I assume not?) First, it seems that GCC does emit MacroFile that has no macros inside (I understand that it might not b...

...e parser, and LLVM IR for testing the Sema. We don't usually do direct AST tests in Clang for debug info (or for many things, really) - we just do source -> llvm IR anyway, so that's nothing out of the ordinary. > I wonder if it'd be better to use a parent chain style approach (DIMacro has a DIMacroFile it refers to, each DIMacroFile has another one that it refers to, up to null)? > (does it ever make sense/need to have a DIMacroFile without any macros in it? I assume not?) First, it seems that GCC does emit MacroFile that has no macros inside (I understand that it might not b...

...e parser, and LLVM IR for testing the Sema. We don't usually do direct AST tests in Clang for debug info (or for many things, really) - we just do source -> llvm IR anyway, so that's nothing out of the ordinary. > I wonder if it'd be better to use a parent chain style approach (DIMacro has a DIMacroFile it refers to, each DIMacroFile has another one that it refers to, up to null)? > (does it ever make sense/need to have a DIMacroFile without any macros in it? I assume not?) First, it seems that GCC does emit MacroFile that has no macros inside (I understand that it might not b...

...; > We don't usually do direct AST tests in Clang for debug info (or for many > things, really) - we just do source -> llvm IR anyway, so that's nothing > out of the ordinary. > > > > > > > I wonder if it'd be better to use a parent chain style approach (DIMacro > has a DIMacroFile it refers to, each DIMacroFile has another one that it > refers to, up to null)? > > (does it ever make sense/need to have a DIMacroFile without any macros > in it? I assume not?) > First, it seems that GCC does emit MacroFile that has no macros inside (I >...

...tests in Clang for debug info (or for many >> things, really) - we just do source -> llvm IR anyway, so that's nothing >> out of the ordinary. >> >> >> >> >> >> > I wonder if it'd be better to use a parent chain style approach >> (DIMacro has a DIMacroFile it refers to, each DIMacroFile has another one >> that it refers to, up to null)? >> > (does it ever make sense/need to have a DIMacroFile without any macros >> in it? I assume not?) >> First, it seems that GCC does emit MacroFile that has no macros insi...

...or >>> many things, really) - we just do source -> llvm IR anyway, so that's >>> nothing out of the ordinary. >>> >>> >>> >>> >>> >>> > I wonder if it'd be better to use a parent chain style approach >>> (DIMacro has a DIMacroFile it refers to, each DIMacroFile has another one >>> that it refers to, up to null)? >>> > (does it ever make sense/need to have a DIMacroFile without any macros >>> in it? I assume not?) >>> First, it seems that GCC does emit MacroFile that ha...

...e termination So I propose to introduce 4 new Generic Macro Types to be used as types, with no dependence to various DWARFv5/v4 forms. 1. MACRO_definition 2. MACRO_undef 3. MACRO_start_file 4. MACRO_end_file - Previous infrastructure uses DWARF forms as types in metadata -- > !DIMacro(type: DW_MACINFO_define, line: 9, name: "Name", value: "Value") And the production part will query this and emits the form present[hardcoded]. Upgraded infrastructure will be using something like -- > !DIMacro(type: MACRO_definition, line: 9, name: "Name", valu...