On 09/17/2015 10:49 AM, David Malcolm wrote:
FWIW, I have a (very messy) implementation of this working for the C
frontend, which gives us source ranges on expressions without needing to
add any new tree nodes, or add any fields to existing tree structs.
The approach I'm using:
* ranges are stored directly as fields within cpp_token and c_token
(maybe we can ignore cp_token for now)
* ranges are stashed in the C FE, both (a) within the "struct c_expr"
and (b) within the location_t of each tree expression node as a new
field in the adhoc map.
Doing it twice may seem slightly redundant, but I think both are needed:
(a) doing it within c_expr allows us to support ranges for constants
and VAR_DECL etc during parsing, without needing any kind of new tree
wrapper node
(b) doing it in the ad-hoc map allows the ranges for expressions to
survive the parse and be usable in diagnostics later.
So this gives us (in the C FE): ranges for everything during parsing,
and ranges for expressions afterwards, with no new tree nodes or new
fields within tree nodes.
I'm working on cleaning it up into a much more minimal set of patches
that I hope are reviewable.
Hopefully this sounds like a good approach
So is the assumption here that the location information is or is not
supposed to survive through the gimple optimizers? If I understand
what you're doing correctly, I think the location information gets
invalidated by const/copy propagations.
Though perhaps that's not a major problem because we're typically
propagating an SSA_NAME, not a _DECL node. Hmm.
jeff
