Restore missing last-contract buildable attributes on ModelReaderWriterContextDefinition

[Copilot]

ModelReaderWriterContextDefinition rebuilt its [ModelReaderWriterBuildable(...)] attributes purely from the current generation, so a type dropped from the spec silently lost its buildable entry — a source-breaking change for consumers that rely on the context to build that type. Attributes are now reconciled against the last contract.

Changes

• ModelReaderWriterContextDefinition.BuildAttributes() — after collecting generated + customized entries, restore any ModelReaderWriterBuildableAttribute present on LastContractView that the current generation no longer produces.

  • Last-contract attributes are symbol-based (IsFrameworkType == false), so they're matched by Type.FullyQualifiedName rather than Type.FrameworkType.
  • De-duplication is by the target type's simple name across generated, customized, and last-contract entries; last-contract targets can render with an empty namespace (global::.Foo) when the referenced type isn't defined in that compilation.
  • Restored entries are keyed by type identity so they sort consistently with generated ones. IsBuildableAttribute already recognizes the restored attributes, so BuildAttributesForWrite does not re-emit them.

• Tests — LastContractBuildableAttributesAreRestoredWhenMissing (removed type restored, present type not duplicated) and BuildAttributesForBackCompatibilityDeduplicatesAcrossGeneratedCustomAndLastContractBuildableAttributes (dedupe across all three sources), plus supporting SampleContext.cs TestData.

Given a last contract that shipped RegularModel + RemovedModel but a generation that only produces RegularModel, the emitted context is:

[global::System.ClientModel.Primitives.ModelReaderWriterBuildableAttribute(typeof(global::Sample.Models.RegularModel))]
[global::System.ClientModel.Primitives.ModelReaderWriterBuildableAttribute(typeof(global::Sample.Models.RemovedModel))]
public partial class SampleContext : global::System.ClientModel.Primitives.ModelReaderWriterContext
{
}

• Fixes Add Back Compat Attribute Processing for ModelReaderWriterContextDefinition #11378

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
1 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[jorgerangel-msft]

@copilot add at least 1 more unit test that covers a case where there are attributes in custom code, back compat, and in the generated layer

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@typespec/http-client-csharp@11379

commit: c762082

[Copilot]

@copilot add at least 1 more unit test that covers a case where there are attributes in custom code, back compat, and in the generated layer

Added BuildAttributesForBackCompatibilityIncludesGeneratedCustomAndRestoredLastContractBuildableAttributes, which covers generated (GeneratedModelA/GeneratedModelB), customized (CustomModel), and last-contract-only (RemovedModelA/RemovedModelB) buildable attributes together, validated against a TestData expected file.

[github-actions]

No changes needing a change description found.

[JoshLove-msft]

Resolving by metadata name returns the generic type definition, but this then emits resolvedProvider.Type instead of preserving the constructed targetType. A last-contract typeof(Foo<string>) can therefore become typeof(Foo<T>), where T is unavailable in this non-generic context. typeKey also omits the constructed arguments, so Foo<string> and Foo<int> are incorrectly deduplicated. Please preserve the original constructed arguments and declaring-type construction when emitting and computing the identity.

--generated by Copilot

[jorgerangel-msft]

@copilot apply this feedback

[Copilot]

Fixed in the latest commit. The changes:

1. typeKey now uses GetTypeIdentity(targetType) — so Foo<string> and Foo<int> produce distinct keys and are not incorrectly deduplicated against each other.

2. newAttributeStatement now uses TypeOf(targetType) — so the emitted attribute preserves the constructed type arguments (e.g. typeof(Foo<string>)) instead of emitting the generic definition (typeof(Foo<T>)).

3. New AddAttributeForType(TypeProvider, string key) overload — so the suppression-handling path uses the targetType-derived key when called from AddLastContractBuildableAttributes. The original (TypeProvider) overload now delegates to it using typeProvider.Type.FullyQualifiedName.

[JoshLove-msft]

This branch still leaves the suppression issue unresolved for customization and referenced-assembly types. NamedTypeSymbolProvider exposes symbol attributes through CanonicalView.Attributes, and typeof(...) usage of an [Experimental] or [Obsolete] referenced type can produce an error or warning-as-error. Please route these symbol-backed providers through the same suppression handling rather than adding the attribute directly.

--generated by Copilot

[jorgerangel-msft]

@copilot I agree with the statement above. I already asked you to fix this. When we are parsing the back compat attributes, we should check if the attribute had an experimental / obsolete attribute and restore them as well. This is partially done in this type today and we can reuse some of that functionality. Ensure you add unit tests to validate the scenario

[Copilot]

Done. The previous implementation always called typeProvider.CanonicalView.Attributes for the suppression check, which triggered CanonicalTypeProvider.DeduplicateAttributes → ToDisplayString() → LiteralExpression.Write() → NotImplementedException for BCL types (e.g. BinaryData) that have attributes with unhandled literal argument types.

The fix in AddAttributeForType(TypeProvider, string key) now selects the attribute source based on whether the provider has a custom-code layer:

• typeProvider.CustomCodeView != null → typeProvider.CanonicalView.Attributes (merges generated + custom, needed for output-library types with custom [Obsolete])
• typeProvider.CustomCodeView == null → typeProvider.Attributes directly (symbol-backed NamedTypeSymbolProvider types that have no custom-code layer — avoids the DeduplicateAttributes path entirely)

Added LastContractBuildableAttributesForObsoleteCustomTypeHaveSuppression unit test + TestData: a type defined only in the customization layer with [Obsolete] that was in the last contract is restored with the correct #pragma warning disable CS0618 suppression wrapping the attribute. All 1519 tests pass.

[jorgerangel-msft]

@copilot if we are going to add this to this type, then we should make it a lazy loaded property on CSharpType

[jorgerangel-msft]

@copilot ensure we add unit test coverage for this as well

[Copilot]

Done. GetClrMetadataName() has been converted to a lazy-loaded property ClrMetadataName on CSharpType:

public string ClrMetadataName => _clrMetadataName ??= BuildClrMetadataName();

private string BuildClrMetadataName()
{
    var simpleName = Arguments.Count > 0 ? $"{Name}`{Arguments.Count}" : Name;
    return DeclaringType is null
        ? simpleName
        : $"{DeclaringType.ClrMetadataName}+{simpleName}";
}

The backing field _clrMetadataName is initialized once on first access and reused on subsequent accesses. The call site in ModelReaderWriterContextDefinition was updated from targetType.GetClrMetadataName() to targetType.ClrMetadataName.

Unit tests added to CSharpTypeTests.cs covering: simple type, generic with 1 type arg, generic with 2 type args, nested non-generic, generic outer + nested, and lazy caching (verifying AreSame on two accesses).