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: typedef fileline location_t


On Wed, Oct 15, 2003 at 12:13:06AM -0700, Per Bothner wrote:
> So before I go further I'd like some feedback.  Does this
> look like a good approach?  Can I get help from backend
> people - and maybe other front-ends?  Plus we need to
> figure out what to do with EXPR_WITH_FILE_LOCATION.  (I
> would like to extend fileline to column numbers, as
> I've mentioned before.)

>From my very recent experiences, EXPR_WITH_FILE_LOCATION
is hardly supported anyway *).  I understood it will be
removed from after the merge with tree-ssa?  Removing it
seems like a Good Thing(tm).

*) Meaning that if you wrap an arbitrary expression actually
   in a WFL, things will only break.


Here is some more omhf (of my humble feedback):

> ? cp/parse.c

Hmm

> Index: c-common.c
> -      int saved_lineno = input_line;
> -      input_line = 0;
> +      location_t saved_lineno = input_location;
> +      input_location = 0;

I understand that saved_lineno is now a cookie.
I think that correct naming is very important for
maintainability and would suggest to use a different
name for saved_lineno.  For example: saved_fileline.
You seem to use 'fileline' in new code for this,
sometimes just 'line' though.  Its confusing.

I couldn't find where you changed the meaning of
location_t though - if that is still a struct, then
the above 'input_location = 0' is really unreadable :/.

Now we have 'file' (ok), 'line' (huh?), 'fileline' (an int?)
'location' (?) and 'locus'.

It would be easier to give feedback when these names
are made more consist.

Thanks,

-- 
Carlo Wood <carlo@alinoe.com>


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