Compilation error: "defined multiple times" (duplicates name from Azure Core, name collision)

[antkmsft]

This affects

• specification/riskiq/Easm
• specification/billingbenefits/BillingBenefits.Management
• specification/iotoperationsdataprocessor/IoTOperationsDataProcessor.Management

It goes like this:

// easm_client.rs

use crate::generated::models::{
    ..., Policy, ...,
};
use azure_core::{
    ...,
    http::{
        ...,
        policies::{..., Policy},
        ...,
    },
    ...,
};

Second example is the same as above, but in models_impl.rs for super::JsonFormat vs azure_core::http::JsonFormat.

Third example is the same as above, but in io_t_operations_data_processor_pipelines_client.rs for crate::generated::models::Pipeline vs azure_core::http::Pipeline.

[antkmsft]

See also #910, #911, and #913

[jhendrixMSFT]

This is going to be tricky to fix.

The easy fix is to change how we import core types.

• use an alias
• don't directly import them and name them by module (e.g. http::JsonFormat instead of JsonFormat)

The first bullet looks cleaner but might not solve all cases. i.e. if we import JsonFormat as CoreJsonFormat there's no guarantee that CoreJsonFormat will be unique. Getting more creative with the alias name could mitigate that (creative names might also hurt readability to some degree).

The second bullet guarantees no collisions but hurts readability. It would be unfortunate to pay that tax everywhere for something that is likely uncommon.

A more robust fix would be to detect when there are collisions and then apply an alias as required, ensuring that the alias is unique (we would alias only the core types when there's a collision). However, it does mean that we must switch to using dynamic type names in the code instead of hard-coding them.

body += `${indent.get()}pipeline: Pipeline::new(\n`;

Would change to something like this.

body += `${indent.get()}pipeline: ${pipelineTypeName}::new(\n`;

Where pipelineTypeName is determined at runtime based on collisions. The complicated part is that we must have the complete import graph before fetching the name for pipelineTypeName.

[antkmsft]

@jhendrixMSFT, could we delegate something of this to use class?
I.e.

use.add('azure_core::http::Pipeline')
...
use.get('azure_core::http::Pipeline') // <-- returns 'Pipeline' in most cases,
// but if there is a collision, returns either 'azure_core::http::Pipeline' or 'CorePipeline',
// per our taste and design choices

And when generating the file, we would front-load the use with the list of entities that we plan to put into this file.
The same way, if we do use.add('azure_core::http::Pipeline'), and then use.add('mylib::Pipeline'), it would detect it.
If there is ever a name collision, get() will startreturning an alternate name for the SDK types.

See also #746 when fixing this, it could make sense if not to combine the work on both items, then to at least maybe make sure we don't make design or implementation choices that would limit fixing the other one.

[jhendrixMSFT]

I was thinking something similar. And for cases where we call add() it returns the token (if needed).

Front-loading Use might be easy in some cases but complicated in others (I think it would be for clients) and is the part I'm thinking about how to solve. We could take an approach similar to ReactJS's "active components" (I forget what exactly they're called) but that seems like it might be a pretty large refactoring. Open to other ideas.

[RickWinter]

Analysis: Name collision between generated types and azure_core types

Problem

When a TypeSpec specification defines a model whose name matches an azure_core type (e.g. Policy, JsonFormat, Pipeline), the generated Rust code produces duplicate symbol imports in the use statements:

use crate::generated::models::{ ..., Policy, ... };
use azure_core::http::policies::{ ..., Policy };

This causes Rust compilation error E0252: the name is defined multiple times.

Three known collision pairs:

1. crate::generated::models::Policy vs azure_core::http::policies::Policy (EASM spec)
2. super::JsonFormat vs azure_core::http::JsonFormat (BillingBenefits spec)
3. crate::generated::models::Pipeline vs azure_core::http::Pipeline (IoTOperationsDataProcessor spec)

Root Cause

In packages/typespec-rust/src/codegen/use.ts, the Use class builds import trees purely by path segments with no collision detection. Both generated and core types are added as unqualified imports. When Use.text() renders the use statements, both conflicting names appear and Rust rejects the duplicate.

Hard-coded azure_core imports exist in clients.ts (e.g., Pipeline, Policy, Request, Method, Url, etc.) and models.ts (e.g., SafeDebug, JsonFormat). These are never checked against model names from the spec.

Plan to Fix

Option A (Recommended): Collision detection with aliasing in Use class

1. In use.ts, track all leaf symbol names across all import trees per file.
2. When addForType() or add() detects a leaf name collision, apply a Rust use ... as ... alias to the azure_core type (e.g., use azure_core::http::Pipeline as CorePipeline).
3. Update Use to expose a get(fullPath) method that returns the possibly-aliased name for use in code generation.
4. Update clients.ts and models.ts to use the aliased name when emitting code (e.g., ${use.get('azure_core::http::Pipeline')}::new(...) instead of hardcoded Pipeline::new(...)).
5. Update helpers.getTypeDeclaration() to cooperate with aliased imports.

Option B (Simpler): Qualify core types by module path

• Always emit azure_core types as module-qualified (e.g., http::Pipeline) instead of importing them. This avoids all collisions but reduces readability.

Consider also issue #746 which may relate to import/use improvements.

Plan to Test

1. Unit test: Add a TypeSpec test case under test/tsp/ with a model named Pipeline (or Policy) to trigger the collision. Regenerate and verify compilation succeeds.
2. Existing crate compilation: After the fix, attempt to generate the three affected specifications (EASM, BillingBenefits, IoTOperationsDataProcessor) and verify cargo check passes.
3. Regression: Run the full regenerate skill and ensure no existing test crates break.