Source generators should be able to handle C# 13 extensions

[eiriktsarpalis]

Source generators that accept arbitrary .NET types as inputs such as STJ, ConfigurationBinder and the logger generator should be updated so that they are able to handle type graphs containing extensions gracefully. Code produced by such generators is usually indexed by System.Type, so they often do not distinguish between different aliases of the same type. Even though some generators (such as CB) don't do this, we still need to make sure that extensions are being handled gracefully and that compatibility with the baseline reflection-based implementation is being preserved.

We need to make sure that the introduction of either implicit or explicit extensions in the type graph does not result in nondeterminstic contracts being generated (i.e. because of extension properties being defined).

cc @ericstj @tarekgh @stephentoub

[eiriktsarpalis]

@333fred could you point to any additions to the Roslyn symbols API that are used to represent extensions?

[stephentoub]

cc: @jcouv

[jcouv]

The Roslyn symbol APIs for extensions have not yet been discussed in details, but likely there will be something indicating whether a type is an extension (TypeKind.Extension and IsExtension), something indicating whether the extension is implicit or explicit (IsExplicitExtension) and something indicating the underlying type.
Tagging the tracking issue for extensions

[eiriktsarpalis]

@jcouv how would implicit extensions work in this case? Whether a type has an implicit extension would be dependent on scope.

[jcouv]

I didn't understand the question. The APIs I described above tell you whether a type is an extension, whether it is explicit or implicit and what its underlying type is. None of the above APIs tell you whether an implicit extension is applicable to a given type in a given scope.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.