Re: Merge cpplib and front end hashtables, part 1

[Daniel Berlin <dan at cgsoftware dot com>]

Per Bothner <per@bothner.com> writes:

> Daniel Berlin <dan@cgsoftware.com> writes:
> 
> > In other words, macro expansion ain't done in the parser, it's called
> > by the evaluator.  It would be a serious hunk of work to move it back
> > into the parser, and then make the parser use cpplib internally.
> 
> Is there currently any macro expansion at all?  I didn't think so,
> in which case there is nothing to move "back".

I have a patch that makes it work, which is how this whole discussion
got together.

I made gcc produce the dwarf2 macinfo section, and gdb use it.

Since I couldn't get CPPLIB integrated quickly, I just made it do
simple macro expansion.

> 
> I really think cpplib expansion should be done by the parser
> (in conjunction with lexing), not the evaluator.  Why do you
> think it needs to be done by the evaluator?

Oh, I don't think it should. It just wasn't worth rewriting the parser
vs inserting 10 lines into the expression evaluation machine.

We only need to disambiguate between function calls and macros when we
go to actually perform the function call, in expression evaluation.

So I did that, and made a simple macro expander.

>  After all, the
> parser already needs access to the symbol table (for typenames).
> -- 

You are welcome to implement this whole glob. I did not.
I won't have time to, for a while.

> 	--Per Bothner
> per@bothner.com   http://www.bothner.com/per/

-- 
"The other night I came home late, and tried to unlock my house
with my car keys.  I started the house up.  So, I drove it
around for a while.  I was speeding, and a cop pulled me over.
He asked where I lived.  I said, "right here, officer".  Later,
I parked it on the freeway, got out, and yelled at all the cars,
"Get out of my driveway!"
"-Steven Wright