Json serializer type discovery

[kevinwkt]

Initial type discovery approach with temporary tests

A few changes in this PR:

1. JsonSerializableAttribute creation in System/Text/Json/Serialization/Attributes/JsonSerializableAttribute.cs
2. Updated Source generator for type discovery along with basic temporary tests.
3. Added ReflectionUtils by David Fowler for type wrappers from roslyn syntax tokens to System.Type.

[layomia]

LGTM - let's file relevant issues and continue documenting our decisions.

[layomia]

Let's create an issue to consider changing this to an assembly level attribute since we are not generating source on the actual types (both owned and not owned) for now, as discussed offline.

If we enable that mode in the future, we'd just need to check that the calling assembly equals the type's assembly, and the type is partial before we generate source on the type.

[ericstj]

Was this issue created? I had the similar feedback here before I found this comment :)

[chsienki]

The trouble with this approach is that you can't guarantee that the attribute name will actually be called "JsonSerializable"

For example, here are a bunch of ways I can rename the attribute https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEBDAzhgHwAEAmARgFgAoIgBgAIBBAOwgwAsYoA5bAWxi4ADtjAx6AXnpEyAbmp16AZQgCOAS2YBzAKIAbXDB3MM62HoCek6WQB0Sruux71AL2zA9MRhgxR1wACuGDDyVNQA2g7+zm4eXgC6CgDM0iRM9ADeAL7UkTL2jrHunt6+/kEhSTSppPQAQlm54VQRLGycPPyCImKFMS4liSlp9ADCTXmtKmrsmroGRiZmMJbVRLXpACJNQA===

Basically when dealing with syntax, you can only make guesses at things, not full decisions. You won't be able to actually know if the same attribute without doing binding. That's what the compiler does when you ask for a semantic model (it's not a trivial operation ;))

The way the other 'attribute based' generators solve this is by just selecting candidates for inclusion (basically anything that has an attribute):
https://github.com/dotnet/roslyn-sdk/blob/94087f6f1d5414ca187d8836caf7c8a114f22978/samples/CSharp/SourceGenerators/SourceGeneratorSamples/AutoNotifyGenerator.cs#L176

Then doing the actual selection during generation. https://github.com/dotnet/roslyn-sdk/blob/94087f6f1d5414ca187d8836caf7c8a114f22978/samples/CSharp/SourceGenerators/SourceGeneratorSamples/AutoNotifyGenerator.cs#L50

As your attribute is provided via references (not injected directly via the generator) you won't need to do the 'create a new compilation' step you'll see above.

[jkotas]

cc @AaronRobinsonMSFT https://github.com/dotnet/runtimelab/blob/DllImportGenerator/DllImportGenerator/DllImportGenerator/DllImportGenerator.cs#L210 seems to have the same issues.

[AaronRobinsonMSFT]

@jkotas Not really. I handle all those cases. I ensure the name ends with GeneratedDllImportAttribute or GeneratedDllImport. This handles all the cases in that example see

runtimelab/DllImportGenerator/DllImportGenerator/DllImportGenerator.cs

Lines 188 to 193 in 35c9adc

	private static bool IsGeneratedDllImportAttribute(AttributeSyntax attrSyntaxMaybe)
	{
	var attrName = attrSyntaxMaybe.Name.ToString();
	return attrName.EndsWith(GeneratedDllImport)
	|| attrName.EndsWith(GeneratedDllImportAttribute);
	}

.

This doesn't handle the other case of TrickGeneratedDllImportAttribute though. Still on the fence whether it is worth addressing based on the cost of building up the semantic model where it is being done.