Re: Enhanced language support for Modula-2

[Gaius Mulley <gaius@glam.ac.uk>]

"Jim Blandy" <jimb@red-bean.com> writes:

> - You need to post a ChangeLog entry along with your patch.

> I have some futher comments mixed in with the patch below.

ok, will do..

> Adding new references to deprecated variables or functions is frowned
> on.  These are bits of interface that we've decided we'd like to get
> rid of over time; every new use is another case that someone trying to
> remove the variable/function needs to consider and understand.

ok,

> Also, this code looks like it's cut-and-paste from c-typeprint.c; does
> HP C (also known as aCC) generate Modula-2 code?  Can't all this just
> go away?

yes I think it can..

> In general, I'm surprised at the structure of the type printing code. 
> All this varspec prefix and varspec suffix crud is there to deal with
> C's weird pseudo-algebraic type syntax, where the parse tree is the
> reverse of the natural type tree.  Surely Modula-2 doesn't imitate
> that --- does it?  Couldn't Modula's types be printed with a
> straightforward tree walk?  Apologies if you've explained this
> before.

the tree walk approach would be much cleaner - and much shorter - I'll
re-implement m2-typeprint.c accordingly.  I originally kept it (cut and
paste) the same as c-typeprint.c, to preserve any debugging
information which Modula-2 does not use, which would allow users to

set lang m2
print s

and see language differences with maybe non m2 constructs written in
C.  I now think this idea is ugly :-) and probably serves little
purpose and would cause confusion anyhow. Now that dwarf2read.c takes
a different approach w.r.t CHAR and char the mixed language approach
makes even less sense.

> 
> > @@ -6153,25 +6179,29 @@
> >      case DW_LANG_C_plus_plus:
> >        cu->language = language_cplus;
> >        break;
> > +    case DW_LANG_Cobol74:
> > +      cu->language = DW_LANG_Cobol74;
> > +      break;
> > +    case DW_LANG_Cobol85:
> > +      cu->language = DW_LANG_Cobol85;
> > +      break;
> 
> Was this code here before?  I'm sorry I didn't catch it the first
> time.  You can't use DWARF language constants as values for
> cu->language; that's GDB's internal 'enum language'.  They're
> completely different enums.

oops terribly sorry, awful mistake..

Thanks for the suggestions about gdb.texinfo and the guidance in
general, - I'll work on all these issues and resubmit in a week or
two.

regards,
Gaius