Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: Matt Rice <ratmice@gmail.com>
Cc: gdb-patches@sourceware.org, Doug Evans <dje@google.com>
Subject: Re: Rename "info definitions"?
Date: Thu, 29 Sep 2011 14:01:00 -0000	[thread overview]
Message-ID: <201109291456.47303.pedro@codesourcery.com> (raw)
In-Reply-To: <CACTLOFpbaBafSjnTXqL9wMEtB39at4Zu0Wqx_Dgac_R2QiC6gQ@mail.gmail.com>

On Thursday 29 September 2011 14:42:42, Matt Rice wrote:
> On Thu, Sep 29, 2011 at 6:28 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> > On Thursday 29 September 2011 14:26:19, Pedro Alves wrote:
> >> We could just add it back if we ever find a need though.
> >> If a language needing it for macros would require adding more
> >> such switches to other commands.
> >
> > Err, I meant, "I suspect a language needing it for macros would
> > require adding more such switches to other commands."
> 
> None of the other macro commands accept options, they just interpret
> the entire string as a
> name currently, so this is a new form of c-ism
> 
> I think all that would be required is just turning the macro printing
> formatters into language based callbacks, and the macro expansion
> parser into language based callbacks.

Still, I'm really not sure doing just that would be a good idea.  You
can always run a C preprocessor on some non-C sources.  If it's a
compiled language, the compiler should be able to output c preprocessor
macro debug info in that case too.  I think that "info macros" and friends
(possibly renamed to c-macros?) should would still operate on the C
preprocessor macros / text expansion level in that case, instead of on
whatever the target language calls macros, and a new command specific
for the language's macros would be added.

> but who knows what you would run into if you actually tried.

Exactly.  :-)

-- 
Pedro Alves


  reply	other threads:[~2011-09-29 13:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-21 19:34 Doug Evans
2011-09-21 20:28 ` Matt Rice
2011-09-23 17:38   ` Doug Evans
2011-09-29  2:16     ` Matt Rice
2011-09-29  7:20       ` Eli Zaretskii
2011-09-29 10:55       ` Pedro Alves
2011-09-29 12:41         ` Matt Rice
2011-09-29 13:28           ` Pedro Alves
2011-09-29 13:37             ` Pedro Alves
2011-09-29 13:56               ` Matt Rice
2011-09-29 14:01                 ` Pedro Alves [this message]
2011-10-03 21:18       ` Matt Rice
2011-10-04 16:51         ` Tom Tromey
2011-10-05  0:31           ` Matt Rice
2011-10-14 20:23             ` Tom Tromey
2011-11-12 17:03               ` Matt Rice
2011-11-12 17:09                 ` Matt Rice

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201109291456.47303.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=ratmice@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox