Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[http-client-csharp] How do we deal with the case when type name collides with namespace #5471

Open
ArcturusZhang opened this issue Jan 2, 2025 · 3 comments · May be fixed by #5443
Open
Assignees
Labels
emitter:client:csharp Issue for the C# client emitter: @typespec/http-client-csharp

Comments

@ArcturusZhang
Copy link
Member

ArcturusZhang commented Jan 2, 2025

Once we enable the tsp namespace feature, we get tons of occurrence of this case:
one of the segment of the namespace collides with one of the existing type name, such as in cadl-ranch case http/client/naming, we have a type Client.Naming.UnionEnum.ClientExtensibleEnum and another client Client.Naming.UnionEnum
Here is a case that one namespace segment collides with a type's name. Spec here: Azure/typespec-azure@111e0b9/packages/azure-http-specs/specs/client/naming/main.tsp#L197

We get this before - but when this happens before, we rename the namespace, see this cadl ranch project:


in this case, the namespace segment collides with BCL type names, therefore we renamed them.

Now the new change uncovers more occurrence of this issue, we need to find a solution to avoid the generated code to fail to compile.

@ArcturusZhang ArcturusZhang added the emitter:client:csharp Issue for the C# client emitter: @typespec/http-client-csharp label Jan 2, 2025
@ArcturusZhang
Copy link
Member Author

Well after a few more investigations, this comes from a fact that might be a design flaw:
In tsp, namespace might become a client in the generated library, and client is a type - therefore this is a 100% percent-triggered scenario, when we have a typespec file which uses a namespace as a client (defines operations inside it), and defines models under it, such as this case: https://github.com/Azure/typespec-azure/blob/111e0b9603c0b2b28415cbecd8d9669945f8b4c7/packages/azure-http-specs/specs/client/naming/main.tsp#L197
In the above case, the namespace itself becomes a type, therefore we have a type: UnionEnum, and in the meantime, the model/enum defined inside this namespace will have the namespace XXX.UnionEnum. Therefore bam! we now have namespace colliding with type names.

@ArcturusZhang ArcturusZhang self-assigned this Jan 8, 2025
@ArcturusZhang
Copy link
Member Author

After offline discussion, we will do this:

  • automatically prepend underscore on the conflict namespace, such as FooService._Foo. The subclient's name is unchanged.
  • produce diagnostic warning when doing so, with a message of guidance about "you could fix this by using clientName or clientNamespace decorators.

@ArcturusZhang
Copy link
Member Author

and it looks like this:

../C:/Users/dapzhang/Documents/Workspaces/typespec/packages/http-client-csharp/node_modules/@azure-tools/azure-http-specs/specs/client/naming/main.tsp:195:11 - warning @typespec/http-client-csharp/general-warning: bad namespace Client.Naming.UnionEnum for client UnionEnum, please use @clientNamespace to specify a different namespace or @clientName to specify a different name for the client
> 195 | namespace UnionEnum {
      |           ^^^^^^^^^

@ArcturusZhang ArcturusZhang linked a pull request Jan 8, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
emitter:client:csharp Issue for the C# client emitter: @typespec/http-client-csharp
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant