Emit decorator list

[chunyu3]

Fix #4031

When we specify the allowed-emit-decorators in emitter, TCGC will help to emit out decoration information for each item (client, property, operation), e.g final-state-var, our .NET input-Model need to contain this information.

This PR will

• emit decorators to all kind of models, operations and operations
• add reference resolve strategy in TypeSpecInputDecoratorInfoConverter to support parse by reference

[azure-sdk]

API change check

APIView has identified API level changes in this PR and created following API reviews.

@typespec/http-client-csharp
Microsoft.Generator.CSharp.Input

[chunyu3]

autorest.csharp regen preview PR: Azure/autorest.csharp#4940

[archerzz]

Do we have a test case where Decorators is not empty array?

[archerzz]

Previously I thought it's quite natural to pass decorators to generator. But after seeing the codes, I hesitate, mainly because:

1. In some cases, we have to process the decorators before passing input json to generator. Do we still need to pass the original data?
2. Swagger input will be converted to input model first. If a metadata happens to exist in both typespec decorator and swagger x-ms-xxx directive, we definitely don't want to covert swagger directive into typespec decorator. We should go approach 1 above.
3. It looks quite painful to parse the DecoratorInfo in csharp.

@m-nash @ArcturusZhang your thoughts?

[chunyu3]

3. It looks quite painful to parse the DecoratorInfo in csharp.

For #1, we only need to pass some special set(which is small) of decorators which may not common, or be special decorators defined in customized typespec library/emitter. Common decorators we will parse the information to our input model and will not pass to generator

#2, I think the swagger derective (all its corresponds typespec decorator) does not belong to the decorators to emit.
#3 We only need to parse known decorator's information (we know the definition/structure of the decorator to parse). Not generic parse for all decorators.

[ArcturusZhang]

Previously I thought it's quite natural to pass decorators to generator. But after seeing the codes, I hesitate, mainly because:

1. In some cases, we have to process the decorators before passing input json to generator. Do we still need to pass the original data?
2. Swagger input will be converted to input model first. If a metadata happens to exist in both typespec decorator and swagger x-ms-xxx directive, we definitely don't want to covert swagger directive into typespec decorator. We should go approach 1 above.
3. It looks quite painful to parse the DecoratorInfo in csharp.

@m-nash @ArcturusZhang your thoughts?

So we could categorize the decorators into two types:
The first type of decorators really changes something on the typespec, such as this. These kind of decorators have done their work in tsp compilation because they changes the type graph, and TCGC does not even feel the existence of them
The second type of the decorators are "flags". They do nothing on the typespec itself, such as the @useSystemTextJsonConverter decorator. For this kind of decorators, it makes sense that we pass through their data to the generator.

I think this should resolve your first concern.

For 2, some extensions will change the spec, for instance some x-ms-format extension changes the type, for this kind of extensions, our code model converter should do their work correctly by convert it to its actual types, and it should never be a decorator in the decorator list. Some other extensions are just flags, these needs to be put into the decorator list.

For 3, you might need to specify. It is always painful when we want to convert an unknown type into C#, it is inevitable.

[archerzz]

Previously I thought it's quite natural to pass decorators to generator. But after seeing the codes, I hesitate, mainly because:

1. In some cases, we have to process the decorators before passing input json to generator. Do we still need to pass the original data?
2. Swagger input will be converted to input model first. If a metadata happens to exist in both typespec decorator and swagger x-ms-xxx directive, we definitely don't want to covert swagger directive into typespec decorator. We should go approach 1 above.
3. It looks quite painful to parse the DecoratorInfo in csharp.

@m-nash @ArcturusZhang your thoughts?

So we could categorize the decorators into two types: The first type of decorators really changes something on the typespec, such as this. These kind of decorators have done their work in tsp compilation because they changes the type graph, and TCGC does not even feel the existence of them The second type of the decorators are "flags". They do nothing on the typespec itself, such as the @useSystemTextJsonConverter decorator. For this kind of decorators, it makes sense that we pass through their data to the generator.

I think this should resolve your first concern.

For 2, some extensions will change the spec, for instance some x-ms-format extension changes the type, for this kind of extensions, our code model converter should do their work correctly by convert it to its actual types, and it should never be a decorator in the decorator list. Some other extensions are just flags, these needs to be put into the decorator list.

For 3, you might need to specify. It is always painful when we want to convert an unknown type into C#, it is inevitable.

@ArcturusZhang thanks. For 3, I just found that we could have a TypeSpecInputDecoratorConverter, so in the future we can have concrete type for the decorators we do care in generator. Problem solved.

I wander if we can identify the type of argument value according to the json-element-type. If not, I will file an request to ask TCGC to emit valueType for the arguments of decorator which will help us to correct convert the value from json.