This is the mail archive of the 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 1/3] (v2) On-demand locations within string-literals

On Fri, 2016-07-29 at 21:42 +0000, Joseph Myers wrote:
> On Tue, 26 Jul 2016, David Malcolm wrote:
> > This patch implements precise tracking of source locations for the
> > individual chars within string literals, so that we can e.g.
> > underline
> > specific ranges in -Wformat diagnostics.  It handles macros,
> > concatenated tokens, escaped characters etc.
> What if the string literal results from stringizing other tokens
> (which 
> might have arisen in turn from macro expansion, including expansion
> of 
> built-in macros not just those defined in source files, etc.)?  "You
> don't 
> get precise locations" would be a fine answer for such cases -
> provided 
> there is good testsuite coverage of them to show they don't crash the
> compiler or underline nonsensical characters.

Good question.  I briefly tested it just now, and it happens to fail
gracefully.  I'll add proper test coverage for this.

> > +	return "range starts after
> Where do these strings get used?  Hopefully not in diagnostics for
> users, 
> as they aren't written in user terms, and any diagnostic string like
> that 
> would need to be marked up to be extracted for translation.

Quoting from the comment for get_source_range_for_substring:

   Return NULL if successful, or an error message if any errors occurred.
   Error messages are intended for GCC developers (to help debugging) rather
   than for end-users.

and various functions in the patch follow this pattern (maybe I need to
add this to more comments?)

I initially had these functions return bool, but found that a const
char * was much more useful when debugging failures.
(In the testsuite I do happen to use it in a diagnostic, but that's in
a plugin, and is purely intended for verifying that various cases are
hitting various error paths - analogous to looking for messages in a


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