<p dir="ltr">Generally we don't encourage source to source translation via code generation from the AST even - its best to use the AST to motivate edits to the original source. The AST just doesn't have the fidelity to regenerate the original source perfectly.</p>

<p dir="ltr">As for your current problem, I guess 'is it cheaper to rewrite in a better way' depends on the complexity, but i assume its hard to justify a rewrite unless this tool is going to live a long time further and need new features/maintenance.</p>

<p dir="ltr">That said, I'm not sure how much I can help you produce debug info for every function declaration. If I were doing this I'd go back and look at the support I added for imported directives (using declarations and directives) and look at other unhandled decks that could be supported. </p>

<div class="gmail_quote">On Nov 9, 2013 10:18 AM, "Lewis Burns" <<a href="mailto:lewisurn@gmail.com">lewisurn@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>I'm fixing an existing source-to-source
      translator, and it was unfortunately written by someone using LLVM
      as the intermediate step before Clang was mature. I don't need to
      generate object code at all, and performance is not a concern
      here.<br>
      <br>
      Sounds like that the only way for me to save this translator is to
      patch Clang by generating debug info metadata for declarations
      whose definitions are not available. Is this a feasible approach?
      I mean how difficult it would be comparing with hacking into Clang
      AST and start from there? I guessed that it would be much easier
      than starting over with Clang AST from scratch. Since I haven't
      worked on Clang before, any suggestion and help would be greatly
      appreciated.<br>
      <br>
      <br>
      <br>
      On 11/09/2013 04:14 PM, David Blaikie wrote:<br>
    </div>
    <blockquote type="cite">
      <p dir="ltr">For those following this thread a critical detail
        would be that you want debug info metadata.</p>
      <p dir="ltr">There's no simple flag for this as we don't attach
        the function debug info metadata to every declaration, just to
        definitions (there's no filtering step)</p>
      <p dir="ltr">But why do you want this anyway? If you're performing
        optimizations/transformations based on debug info metadata,
        that's not really the desired approach. Debug info is not meant
        to affect code generation.</p>
      <div class="gmail_quote">On Nov 9, 2013 7:59 AM, "Lewis Burns"
        <<a href="mailto:lewisurn@gmail.com" target="_blank">lewisurn@gmail.com</a>>
        wrote:<br type="attribution">
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div text="#000000" bgcolor="#FFFFFF"> Hi,<br>
            <br>
            I haven't worked on Clang before and have a simple question
            (supposedly) for those who are familiar with metadata and
            LLVM bitcode generation. Assume that I have a function which
            is declared as extern as the following:<br>
            <br>
            <font face="Courier New, Courier, monospace">extern int
              convert(unsigned u);</font><br>
            <br>
            I want to have Clang generate metadata nodes for it by
            adding a metadata node of subprogram into the list of
            subprograms defined in the current compilation unit. The
            subprogram metadata node and its associated nodes should
            have the info of the type signature. For example, I get the
            following set of metadata nodes for function<br>
            <font face="Courier New, Courier, monospace"><br>
              int convert(unsigned u) {return 0;}<br>
              <br>
              !3 = metadata !{metadata !4, metadata !10, metadata !33}<br>
              !4 = metadata !{i32 786478, metadata !1, metadata !5,
              metadata !"convert", metadata !"convert", metadata !"",
              i32 23, metadata !6, i1 false, i1 true, i32 0, i32 0,
              null, i32 256, i1 false, i32 (i32)* @convert, null, null,
              metadata !2, i32 23} ; [ DW_TAG_subprogram ] [line 23]
              [def] [convert]<br>
              !7 = metadata !{metadata !8, metadata !9}<br>
              !8 = metadata !{i32 786468, null, null, metadata !"int",
              i32 0, i64 32, i64 32, i64 0, i32 0, i32 5} ; [
              DW_TAG_base_type ] [int] [line 0, size 32, align 32,
              offset 0, enc DW_ATE_signed]<br>
              !9 = metadata !{i32 786468, null, null, metadata
              !"unsigned int", i32 0, i64 32, i64 32, i64 0, i32 0, i32
              7} ; [ DW_TAG_base_type ] [unsigned int] [line 0, size 32,
              align 32, offset 0, enc DW_ATE_unsigned]<br>
            </font><br>
            which allows me to extract the source-level type signature
            for the function by using LLVM debug info APIs. I'd like to
            get the source-level type signature of the extern declared
            function, but Clang does not produce metadata for it.<br>
            <br>
            By looking at the Clang AST for the extern declared function<br>
            <br>
            <font face="Courier New, Courier, monospace">|-FunctionDecl
              0x70598c0 <line:23:1, col:30> convert 'int (unsigned
              int)' extern<br>
              | |-ParmVarDecl 0x7059800 <col:20, col:29> u
              'unsigned int'<br>
            </font><br>
            I know that Clang has the information I need, and I just
            need to turn off or remove the filter that ignores functions
            whose bodies are not available during metadata node or/and
            code generation. Are there simple switches that do this? If
            not, can anyone please explain how to do it by pointing me
            to the right code snippets?<br>
            <br>
            Thanks very much,<br>
             <br>
            <pre cols="72">-- 
Lewis</pre>
          </div>
          <br>
          _______________________________________________<br>
          cfe-dev mailing list<br>
          <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
          <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
          <br>
        </blockquote>
      </div>
    </blockquote>
    <br>
    <br>
    <pre cols="72">-- 
Lewis</pre>
  </div>

</blockquote></div>