Per Bothner wrote:
Robert Dewar wrote:
Right, so it seems quite appropriate to have two representations for
source locations, one for the Ada tree, which is completely independent
of the tree IL, and one for the back end. That probably means that back
end messages will lose the generic instantiation information, but that's
not terrible.
First, the mapped source_location values can encode nested context.
This is used for the C/C++ include file context. I think it is quite
possible to use the same mechanism for generic instantiation
information.
I agree it is quite possible, though there are other issues
besides the nested context for the front end.
Second, the backend *currently* has no support for "generic
instantiation information" so I really don't understand your
point about "losing" this information. You *might* lose it
if you switch to using source_location in the front-end (but
see my first point), as I've argued for in the past, but if
you're translating internal source location to back-end
representation at tree conversion time, which seems to be
your preference, then I don't understand your point.
To be investigated, it really depends on when gigi switches
the representations, and when error messages are issued. It
is quite true that the real back end messages (which are
largely irrelevant for Ada users), do not have the full
source information (that's true now). It is the error messages
issued by gigi that are my concern. But I really don't know
enough to be sure. Anyway, my previous point was that if we
lose some information on those messages, it's not a big deal,
nearly all significant warnings and errors are issued by the
front end, and long term plans move in the direction of
depending even less on the back end messages than we do now.
