This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: typedef fileline location_t
- From: Carlo Wood <carlo at alinoe dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 15 Oct 2003 18:48:38 +0200
- Subject: Re: typedef fileline location_t
- References: <3F8CF382.2030200@bothner.com>
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>