Re: Preparatory PATCH for pretty-print

[Pop Sébastian <pop at gauvain dot u-strasbg dot fr>]

Hi,

Thanks for your work on the C/C++ pretty printer.


On Tue, Jul 30, 2002 at 03:06:20AM +0200, Gabriel Dos Reis wrote:
> Devang Patel <dpatel@apple.com> writes:
> 
> | Is there any place where I can look to find some info. about 
> | pretty-printing ?
> 
> Hmm, I don't think there is any place in the GCC documentation where
> pretty-printing (in the front-ends) is mentioned -- although it's done
> in various forms for the RTL.
> 
> | I want to know what is pretty-printing ?
> 
> What I'm doing is just to render the tree-representation (built by
> the C or C++ front-ends) into a human readable form -- usually as a
> GNU C/C++ program constructs.  
> 
> The goal actually is two-fold: (1) make it possible to visualize the
> effects of various tree-level transformations on program sources; 
> (2) improve the C/C++ diagnostics reporter.
> 
> | My initial impression is that it will beautify source, though I may be 
> | totally wrong.
> 
> Well, the intent isn't to build an "indent"-clone into GCC although
> I'll try hard to make the output the "best" readable as possible.

Here are some things that would be nice to have in the pretty printer:

1.  Include comments from original source code
I know that this would require to store comments with their original line number
and modify the preprocessor in order to keep comments (or transform comments 
in such a way we're able to redump them at the right place.)
This will not destroy completely the source structure and

2.  Another feature, similar to the previous one, is dumping the right name 
for enum elements.  This could improve readability of pretty-printed dumps.
(do you have something that does that in diagnostics files ?)

3.  store macros names and dump them instead of the expansed macro

4.  store file inclusions (and don't dump header files contents)

5.  Make pretty printers output compilable.

All these features are not really needed for debugging purposes; however they
would be useful for users who want to use the compiler as a source to source 
transformer (and for example verify that GCC does the right optimization on
their code). 

> Future works include "styles" -- but I have enought for the time being :-) 
> 
Maybe this feature is not needed (since you can always pass pretty printer's 
output to indent).

> | 
> | I hope, you are also planning to include Objective-C.
> 
Hmm, here again this is not needed for developping source level optimizations, 
but yes it would be nice to have the same syntax on output (from the user's 
point of view :-) ).

Here is a patch that does a minimum for enable ObjC pretty printer to work
(with pretty printer version in tree-ssa branch):
http://gcc.gnu.org/ml/gcc-patches/2002-06/msg00797.html

I wrote: 
> For example you'll see:
> printf ("%s\n", objc_msg_lookup (objc_msg_lookup (aString, &_OBJC_SELECTOR_TABLE, "Hi!"), &_OBJC_SELECTOR_TABLE + 2))
> instead of the original:
> printf ("%s\n", [[aString stringWithString:"Hi!"] cString]);

I think that this form is enough for debugging purposes. 

> Well, Objective-C isn't currently on my radar-screen but if you think
> there are opportunities to reuse what I'm doing for the C/C++
> front-ends then, please just submit a patch.
> 

In fact there's nothing else to do than imitating C behaviour for dumping ObjC nodes.
The patch above uses the following code:

void
objc_pretty_print_node (buffer, node)
     output_buffer *buffer;
     tree node;
{
  if (node == NULL_TREE)
    return;

  switch (TREE_CODE (node))
    {
    case CLASS_INTERFACE_TYPE:
    case CLASS_IMPLEMENTATION_TYPE:
    case CATEGORY_INTERFACE_TYPE:
    case CATEGORY_IMPLEMENTATION_TYPE:
    case PROTOCOL_INTERFACE_TYPE:
    case KEYWORD_DECL:
    case INSTANCE_METHOD_DECL:
    case CLASS_METHOD_DECL:
      NIY;

    default:
      /* The default behaviour is that of a C node.  */
      c_pretty_print_node (buffer, node);
      break;
    }
}


-- Sebastian