`@Function`, `@Field`, and `@Class` responses should include populated `location`

[bkonyi]

The location property for @Function, @Field, and @Class is technically marked as optional in the specification for legacy reasons, but should always be provided in order to allow for these objects to be associated with a parent script. Having location information also allows for us to determine where the code is in a script without having to request the full object.

This is blocking program explorer from working correctly with dwds.

[annagrin]

We were planning to provide precise locations via debug symbols metadata, which is still in progress. That will take time though as it requires DDC to provide the symbols, and significant changes in dwds.

@leonsenft you had a similar request and tried to work around it, do I understand correctly that workarounds using source maps are not working as well as expected?

[leonsenft]

Correct, I was unable to find a suitable workaround. I wanted a way to jump to the definition of a class. The best I could do was jump to a constructor, but that was unreliable depending on the number of parameters the constructor had, and sometimes just didn't work at all and would jump into JavaScript.

[bkonyi]

@nshahan is this location information available now?

[nshahan]

The debug symbols project referenced above was deprioritized so that hasn't happened yet but there are no technical blockers for it in the future. AFAIK this is still a deficiency of Dart centric debugging on the web.