Source location information

[Maurizio Cimadamore]

Thanks for writing this Paul.

 From my reading, it seems that:

* Using optional attributes is nice. The overhead it adds to the API 
(e.g. factories) might be on the "too much" side of things, but of 
course that depends on what other stuff can also use optional 
attributes. E.g. this discussion needs to be closely coupled with a 
discussion on how to model stuff like annotations in the code (e.g. 
local var annotations, or in the type of a cast). If there's a more 
general annotation mechanism, then having it reflected in all the 
factories might not be so bad. If it's just for source location, I agree 
it feels a tad odd.

* The verbosity of the annotation might be reduced (as was suggested 
here) by having an op "inherit" the location from its dominator (when a 
location info is absent)

* The location-like Op is what came to mind first when reading the doc. 
It is similar to how the classfile API handles this kind of stuff. There 
is an advantage in making everything part of the code model in an 
explicit way, as it's rather easy to filter out stuff you don't want. 
Hannes suggestion of using a block is also nice, but might make 
filtering a bit harder.

* Using a Map is not bad either but this feels more like side-stepping 
the question - that is, how is the map populated in the first place? 
E.g. using a map vs. direct API on Op seems like a decision on how the 
source info should be _exposed_, not how it is _modelled_.

* Similarly, using op definitions to attach location info is attractive, 
but, given we don't know whether definitions are there to stay, such a 
decision would be risky (e.g. if we do get rid of op definitions, then 
we'd be back at square one?)

Cheers
Maurizio

On 29/03/2024 20:29, Paul Sandoz wrote:
> Hi,
>
> Attached is a document discussing support for source location in code models. It briefly presents some possible approaches and requirements, and does not (yet) choose a specific approach and describe in more detail (because I don’t know what that should be).
>
> Paul.
>