On 07/29/2016 11:27 AM, David Malcolm wrote:
On Fri, 2016-07-29 at 17:53 +0100, Manuel López-Ibáñez wrote:
On 29 July 2016 at 16:25, David Malcolm <dmalc...@redhat.com> wrote:
FWIW, it appears that clang uses the on-demand approach; the
relevant
code appears to be StringLiteral::getLocationOfByte:
http://clang.llvm.org/doxygen/Expr_8cpp_source.html#l01008
As far as I know, llvm doesn't do language diagnostics from the
middle-end/LTO. Thus, they do not have those problems.
If you really want to have middle-end diagnostics from LTO, I can make
the on-demand approach work.
I can also do the stored-location approach, but it would mean rewriting
all the patches again, I think, would be less efficient.
I would prefer the on-demand approach.
Who is empowered to make a decision here?
ISTM we've got a bit of a deadlock here with the two intertwined
patches. I'm wondering if we can move both forward, perhaps without the
higher quality diagnostics for Martin's work initially. Then iterate on
what's in-tree to add the higher quality diagnostics, then figure out
how to deal with some of the issues we have in the LTO space.
Martin's model of running early or late depending on flags is, IMHO, the
right approach. And more generally its a good solution for other
problems in this space. With that in mind, finding a way to get at the
diagnostics framework from within the middle end and eventually LTO is,
IMHO, important.
Given that the diagnostics are the uncommon case, I would strongly
prefer an on-demand approach rather than recording a ton of stuff in the
front-end for the unlikely case that we're going to want a diagnostic in
the middle-end or LTO.
Jeff
