The alternative approach would be to change getLocation() in the given types. getLocation() is supposed to give the natural location for reporting, and I wonder whether there are any uses/needs of the fuller location (that I'm guessing spans the entire class)? If not, consider overriding getLocation() instead.

If you still need the "full location" around for some reason, then consider adding it as a predicate on ASTNode. Location getLocation() { result = getFullLocation() } or something like that, then you can override it as needed instead of switching on type.

The alternative approach would be to change getLocation() in the given types. getLocation() is supposed to give the natural location for reporting

Is there any CodeQL language that does anything like that? All I've seen is that getLocation() returns a location that spans the entire node.
That is also the behavior that feels the most natural to me, so I think I would prefer an Location getFocusedLocation() instead of a Location getFullLocation().
But in the end that would do basically what I've done here, just spread out in each of the AST classes.

Do you know if we have any documentation on what getLocation() is supposed to do?
All I can find is information on what the structure of getLocation() should be.

Is there any CodeQL language that does anything like that? All I've seen is that getLocation() returns a location that spans the entire node.

This is not the exact same setup as what is being discussed here, but for many Python AST elements, the location (as emitted by the extractor) is not the same as what is spanned by the entire AST node.

An example of this is if-statements, where the "location" actually corresponds to the location of the condition that is being tested.

Suffice it to say, I'm not a fan of doing it in the extractor (there's a sizeable chunk of python.tsg devoted to "reapplying" these position hacks).

I like the idea of moving this into overrides on getLocation instead. I'll probably do that for Python the next time I clean up the parser.

Is there any CodeQL language that does anything like that? All I've seen is that getLocation() returns a location that spans the entire node.

The location of Java classes are just the location of the class name rather than spanning the entire class definition, so there is at least some precedence.

The location of Java classes are just the location of the class name rather than spanning the entire class definition, so there is at least some precedence.

Hmmm.
OK. I'll try to do an approach where I have getLocation() return the "focused" location, and a getFullLocation() that returns a location that spans the entire AST node.
That also means that a QL-for-QL query writer don't have to remember to "focus" the location of e.g. classes when writing a new query.

OK. I'll try to do an approach where I have getLocation() return the "focused" location, and a getFullLocation() that returns a location that spans the entire AST node.

Done.
getFullLocation() is currently unused.
But I'm definitely going to use getFullLocation() in CodeQL-patch after this PR has been merged.

I rebased on main and squashed the history down to a single commit.