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 > > LINE_MAP_MAX_LOCATION_WITH_COLS"; > > 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 dumpfile). Thanks Dave
