On Wed, 19 Sep 2012, Arnaud Charlet wrote: > OK, so you mean, instead of knowing the number of locations from the > tree kind (e.g. 1 extra sloc for unary exprs, 2 for binary exprs, ...), > we would encode this as part of the extra loc info? Note that the number of
No, I mean that rather than the front end using an interface defined as "set the first location to A and the second location to B" it should use one meaning "set the first operand's location to A and the second operand's location to B" or "set the beginning of the range to A and the end of the range to B" - the extra locations should in some way be tagged to indicate what their relation is to the expression, and users of the locations should then also look things up by tag rather than knowing that internally the first location for a binary operation has some particular semantics. As illustrated in the example I gave, there's more than one way one might naturally associate two locations with a binary operation, hence the desire for code to operate on them at a better-defined level than "first" and "second" locations. If you then want to insert a third location in the middle (the location of the operator, say) then you don't need to change everything that referred to locations symbolically. -- Joseph S. Myers jos...@codesourcery.com
