This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ PATCH] Fix mangling of COMPOUND_EXPR


Giovanni Bajo wrote:
Nathan Sidwell <nathan@codesourcery.com> wrote:

The logic behind build_x_compound_expr and build_compound_expr is to go
recursively through the list, lookup overloading of the comma operator,
check for some little semantic property and then build (bottom-up) a tree of
COMPOUND_EXPR, each one with only two operands (and the type of the second).
I'm fairly certain that's a hold over from the old parser. I can't think
why we cannot change things so COMPOUND_EXPRs get constructed in the same
way as any other binary operator. PLUS_EXPR calls build_nt inside a template,
why can't COMPOUND_EXPR?

Now, since within templates we postpone everything to template
instantiation, the quickest and safest way to reuse these two build
functions is just to store the list built by the parser somewhere. Thus,
within templates, the list is stored within the first operand of
COMPOUND_EXPR; at tsubst time, the list gets tsubst'd and then
build_x_compound_expr is called on the resulting list.

If we want to avoid this, we should heavily modify the way the two build
functions work, and the way the parser calls them. Do you think it's worth
it? After all, there should be only a few points where we mess with
changing the way build_x_compound_expr works is probably a necessary step
towards 2-phase name lookup.

If you want to have a go at the conversion, go ahead :)

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
         The voices in my head said this was stupid too
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]