[Bug]: TCGC generates incorrect cross-language definition IDs

[tjprescott]

Describe the bug

See: https://apiview.dev/Assemblies/Review/e3195e5ca7954296b4e68393eb084773#ModelClient.generateImages

The cross-language definition ID for this operation should be ModelClient.getChatCompletions. However, TCGC is transforming the TypeSpec through it's client decorators and so forth and generating an ID of Customizations.Client1.create. The method to generate the cross-language definition ID should not apply any such customizations.

The whole point of the cross-language definition ID is to be the same no matter the language. If a client.tsp applies different customizations for different languages then there's no way those IDs will match.

Reproduction

1. Create a simple TypeSpec.
2. Apply TCGC customizations.
3. Generate the mapping file.

Checklist

• Follow our Code of Conduct
• Check that this issue is about the Azure libraries for typespec. For bug in the typespec language or core libraries file it in the TypeSpec repo
• Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.

[tadelesh]

two problems here:

1. i wonder how we could identify whether an operation is from customization and find its source operation? if there a way that we could know a definition is from client.tsp file?
2. idw whether if we will add more customization which could make find source impossible. i want to know what the rule of cross-language definition id?

[iscai-msft]

1. I'm not sure about that, that's a good point though, @tjprescott any ideas?
2. We want cross language definition id to be the same for the tsp definition, and for all of the language emitters, so we shouldn't have any client customizations included in it

[tjprescott]

@iscai-msft is correct, in order for the cross-language ID to be "cross-language" you can't apply language specific customizations. The only source of truth is the TypeSpec, so the cross-langauge ID should always correspond to the TypeSpec ID.

If you can't trace something back to pure TypeSpec then there would be no cross-language ID. So if you had, for example, a decorator that created some kind of helper operation, there's be no cross-language ID for that helper, but it would only exist in Python.

[mikeharder]

I have no idea how my fork of branch typespec-azure could have triggered this issue to be closed.

@timotheeguerin, @markcowl: Any ideas?

https://github.com/mikeharder/typespec-azure/commit/3af118a4a6a6a0dacfcd8f37847091948d9d3b37

[mikeharder]

I think it happened when I merged upstream to my fork:

Which I think means, this may keep getting re-closed when anybody merges their fork. Which means, you can't really re-open an issue if it was closed by a commit to main.

@tadelesh: I recommend you open an new issue and close this one.

[tadelesh]

@mikeharder ok. thanks for reminder.

[tadelesh]

replaced by #961