https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #35 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #13)
> I guess the C/C++ FEs could for non-trivial string literals put into a hash
> table mapping from locus_t (of ADDR_EXPR around STRING_CST) to the first cpp
> token for that string, then the diagnostic code could go from there.
> Trivial string literal above would be a string literal that doesn't have any
> prefixes (L/u/u8/U and variants with R), isn't contatenated from several
> parts
> and didn't need to be translated. So, printf ("%.*d"); (the common case)
> wouldn't have to be recorded, while printf (R"<<<(%)>>>" "." R"(*)" "d");
> would need that. For "trivial" string literals you'd just shift the locus
> by the offset, for non-trivial look up the tokens and process them again,
> looking at where the corresponding byte would appear to come from.
Perhaps we could use ADHOC_LOCATIONS to implement this? That is, for
multi-string/prefixed string constants, the adhoc data could contain the
additional location. Then, on-the-fly offset locations could be generated by
looking at each piece, if the offset is longer than the piece, then try the
next piece and adjust the offset for the characters already seen in previous
pieces. Simple strings will not have any adhoc data, so they will work as
usual.
