> Hi Honza, > > and thanks for the analysis, now I understand the issue a little more. > > On 09/07/2013 10:28 AM, Jan Hubicka wrote: > >So it is just an accident that the line info is output sanely (if > >line 9 is sane, I don't exactly know) > I would say that in general it's definitely sane, because that is > the instantiation point. And 10 is wrong, too late, it points to the > closing bracket. > > However, I notice that clang doesn't even try to output a message > having to do with line 9: if I understand correctly, if that > operator cannot be mangled, that happens unconditionally, isn't > something that may succeed. Thus I wonder if, instead of outputting > garbage line numbers we could at least suppress in such cases the > whole "In instantiation of..." part of the diagnostic, it would be > better than garbage. Do we have a mechanism for that?
It seems to be what older GCCs are doing, too. > > Now I also understand that this should be a very uncommon error > message, but, I'm wondering, is it possible that other errors, for > other issues, are also affected? That is, other diagnostic happening > very late and sensitive to the recent rework? Any use of source_location from DECL_ASSEMBLER_NAME hanghook is wrong, since source_location may point anywhere when the lazy mangling is triggered. It surprised me that DECL_ASSEMBLER_NAME triggers error/warning messages. It is up to backend when on at what symbols it will call it, so it is definitely source of inconsistency. So from design point of view I would preffer C++ FE to output these errors somewhere else. But practicaly we can perhaps just modify the message to not expect thelocation? I am just leaving for flight to Pisa, will be back online at the hotel. Honza
