Enhanced language support for Modula-2

[Jim Blandy]

Gaius Mulley <gaius@glam.ac.uk> writes:
> Jim Blandy <jimb@codesourcery.com> writes:
>
>> Have you written ChangeLog entries for this?  Follow the format the
>> other entries use.
>> 
>> In GDB code, each curly brace gets a line to itself.  I see a few
>> sharing a line with an 'if' or 'else' in m2-valprint.c and
>> m2-typeprint.c.
>
> Hi Jim and Eli,
>
> sure ok, have done..
>
>> Also, all GNU code should fit in eighty columns.
>
> ok, now fixed..
>
>> I see some indentation problems in m2_val_print.  If you're using GNU
>> Emacs, just hit M-C-q before the function's opening brace, and it'll
>> take care of it.
>
> yes I use emacs for most things.. but I hadn't come across this short
> cut though.. very useful and I believe all is now fixed..
>
>
>
> also enclosed is a proposed set of ChangeLog entries:

Looks great!

Two points to fix when you commit; don't bother re-posting the patch
for review:

- There's still an overly long line in m2-valprint.c, in the
  TYPE_CODE_STRUCT case.

- Similarly, there's a separate ChangeLog for the doc directory; the
  entry for your change to gdb.texinfo should go in gdb/doc/ChangeLog,
  not gdb/ChangeLog.  And generally, we put section names in parens
  after the filename, as we do for functions in C files.  Like so:

      * gdb.texinfo (M2 Types): New section.

I see that you have a copyright assignment on file.  Do you have
commit access to GDB?  If not, we'll have to get you set up with that
first.

If you do, then make a commit to gdb/MAINTAINERS, adding yourself to
"Write After Approval", with an appropriate ChangeLog entry.  Then go
ahead and commit the rest of the patch.