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: [patch] diagnostics branch


>>>>> "Aldy" == Aldy Hernandez <aldyh@redhat.com> writes:

Richard> Is there a plan to remove EXPR_LOCUS in favour of EXPR_LOCATION,
Richard> now that we've ditched the locus struct?  In particular, should
Richard> you be adding new uses of EXPR_LOCUS?

Aldy> It wasn't on my agenda, but perhaps we should remove it in the near
Aldy> future.  The reason I used EXPR_LOCUS in the case above is because a few
Aldy> lines down we used SET_EXPR_LOCUS, so I was keeping with the style.

There's a pending patch to remove EXPR_LOCUS:

http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01871.html

It is on hold, I forget why.

Richard> Why did you need to record the switch condition explicitly, rather
Richard> than examining EXPR_LOCATION (expr)?  There are lots of other places
Richard> around the parser where you do similar things, so I assume there's
Richard> a good reason but I can't think what it might be.

Aldy> Imagine this:

Aldy> 	switch(foo) {
Aldy> 	}

Aldy> EXPR in this case is the VAR_DECL for foo.  And we obviously don't want
Aldy> the location for the declaration of foo, but for the condition "(" (or
Aldy> thereabouts).

This seems like one of those cases where you would ideally want the FE
to have a lot more tree nodes, and in particular have
location-carrying nodes for constants and variable references
(separate from declarations).

That's a lot more work though.

Tom


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