Point of interest metadata for souce generators

[taori]

I want to propose the following idea: Generating points of interests for an IDE to associate specified source locations with a generated symbol.

Why?

I am using https://github.com/CommunityToolkit/dotnet whenever i run across something where MVVM makes sense. However whenever i do use it there are some complaints by pretty much every developer that they do not like that for a generated properties, control-clicking will lead them to a generated property instead of the field that it was generated from. And indeed this is bothersome, because the workaround is always to navigate to the class, then look for the field that generated the property.

The essential part for navigation to provide a way of navigating from a generated property is to add metadata that enables an IDE to also offer a navigation to the field that it origins from.

Perhaps @Sergio0694 has some information on whether this complaint is a regular thing or if it is just the people i work with.

But i imagine metadata + IDE support = more productivity would be something really nice.

[333fred]

This type of thing is why we added partial properties; as I understand it, the toolkit only allows for partial properties in preview mode, as they also use field. However, once C# 14 comes out and field is no longer in preview, you will be able to just declare your properties directly, and the toolkit will use those, rather than the workaround of declaring manual fields that is used currently.

[taori]

That is very useful. nice

[taori]

However i feel that for cases where declaring properties is not the desired behavior there could still be a use in providing that metadata. Then again this scenario is the strongest sample for having it i can think of currently. Maybe MeltyPlayers scenario does make more sense if at least CT.MVVM fixes this usage issue soonish

[MeltyPlayer]

I have a specific use case that’s very closely related to this proposal, just wanted to add it here for consideration.

Recently, I've been working on a source generator for defensive readonly views into types. This is basically meant to be an automated way to generate "IReadOnly" types similar to IReadOnlyList and IReadOnlyDictionary. The generated "IReadOnly" interface substitutes in readonly versions of types where possible, to ensure the generated code is deeply readonly. So the generated readonly properties/methods are often different definitions from what the user defined in their mutable version of the type.

Here’s an example of how that looks in practice, from one of my unit tests:
https://github.com/MeltyPlayer/Schema/blob/main/Schema%20Tests/readOnly/ReadOnlySubstitutionTests.cs#L155

This works, but since the definitions are different, the IDE now jumps to generated code instead of the original code referenced by the source generator, and it’s harder to track usage because it’s split between the mutable/readonly versions.

It would be nice to be able to link them together in the IDE somehow, presumably via an attribute. Perhaps to treat them as a single entity, or to mark the readonly definition as dependent on the mutable definition.