Backmerge/release/may 2026 2026 06 02#4534
Merged
Merged
Conversation
…4440) `@@usage` and `@@access` augment decorators applied to models from imported libraries (e.g. `Azure.Core.Foundations.Error`) were silently dropped when the target was not also reachable from an operation, so the model never appeared in `sdkPackage.models`. ### Root cause `listOrphanTypes` (introduced in #4041) walked `listAllUserDefinedNamespaces`, which filters out namespaces from imported npm packages. Tagged models in those namespaces were never added to `__referencedTypeCache`, so `updateUsageOverride` never saw them and emitters never received them. ### Changes - **`internal-utils.ts` → `listOrphanTypes`**: rewritten to drive iteration off `listScopedDecoratorData(context, usageKey)` and `listScopedDecoratorData(context, legacyHierarchyBuildingKey)` — the strategy originally used by #4024 — so tagged types are discovered regardless of which namespace owns them. When `@@usage` targets a namespace, the walk now recursively descends into sub-namespaces (matching the pre-#4041 behavior). Templates are skipped and `isTypeNeedsHandling` is respected. Result is still cached on `__orphanTypesCache`, preserving the stable ordering #4041 relied on. - **`decorators.ts` → `getUsageOverride`**: made recursive so `@@usage` applied to a namespace propagates to types nested in sub-namespaces (mirroring the existing recursive behavior of `getAccessOverride`). - Dropped now-unused `getUsageOverride` / `getLegacyHierarchyBuilding` imports. - Added regression test in `decorators/usage.test.ts` applying `@@usage`/`@@access` to `Azure.Core.Foundations.Error` and asserting it surfaces in `sdkPackage.models`. - Added regression test for `@@usage`/`@@access` on a namespace propagating recursively through 3 levels of nested namespaces. ### Repro now passes ```tsp import "@some-org/some-lib"; // exports SomeLib.SomeModel namespace MyService; op doThing(@Body body: SomeLib.SomeModel & SomeMixin): SomeResponse; @@Usage(SomeLib.SomeModel, Usage.input); @@access(SomeLib.SomeModel, Access.public); ``` `SomeLib.SomeModel` now appears in `sdkPackage.models` with `usage: Input`, `access: public`. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: tadelesh <1726438+tadelesh@users.noreply.github.com>
Hotfix release for @azure-tools/typespec-client-generator-core 0.68.1 ## Changes - [TCGC] Honor @@usage/@@access on models from imported libraries (#4440) ## Checklist - [x] Version bump via `pnpm chronus version --ignore-policies` - [x] Only TCGC package changed - [x] Core submodule pointer unchanged Co-authored-by: tadelesh <chenjieshi@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…erRide (#4477) The parameter-modifying client customization functions (`reorderParameters`, `addParameter`, `removeParameter`, `replaceParameter`) and the `@override` decorator crashed with `TypeError: Cannot read properties of undefined (reading 'properties')` when the operation argument could not be resolved (for example, a typo like `MyService.NotExists`, as in the playground link from the original issue): ```tsp op original( @typeChangedFrom(Versions.v2, int32) @query a: string, @query b: string, ): void; @@OverRide(original, reorderParameters(MyService.NotExists, #["b", "a"])); ``` ### Root cause The functions in `packages/typespec-client-generator-core/src/functions.ts` and `$override` in `decorators.ts` accessed `operation.parameters.properties` without first checking that the `operation` argument was a real `Operation`. When the user passed an unresolvable reference, the value was not a valid `Operation` and the property access threw. Additionally, `cloneModelProperty` created a new `ModelProperty` via `tk.modelProperty.create` but never called `finishType`, so decorators copied onto the clone were not applied. ### Changes - **`functions.ts`**: add a `validateOperation` helper that emits a new `invalid-function-argument` diagnostic and returns the input unchanged when the operation is not a valid `Operation`. Called at the entry of `replaceParameter`, `removeParameter`, `addParameter`, and `reorderParameters`. Call `tk.type.finishType` on cloned model properties and on cloned operations after re-assigning decorators, so copied decorators are applied. - **`decorators.ts`**: add the same defensive validation at the start of `$override` for both the `original` and `override` arguments. - **`lib.ts`**: add the new `invalid-function-argument` diagnostic with a generic message (`Invalid argument passed to function "${functionName}".`) so it can be reused for all scenarios. - **`reorder-parameters.test.ts`**: regression tests for both an unresolvable operation reference and a `@typeChangedFrom` parameter under a `@versioned` service (using `"api-version": "v1"` when creating the SDK context). - **Chronus changelog**: `fix` entry for `@azure-tools/typespec-client-generator-core`. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: tadelesh <1726438+tadelesh@users.noreply.github.com>
`@clientName` can be applied to any type, but `isExactName` was only
tracked on a subset of TCGC types — leaving emitters unable to detect
`exact()` overrides on clients, service methods, and enum values.
### Interface additions
Added `isExactName: boolean` to:
- `SdkClientType`
- `SdkServiceMethodBase` (inherited by basic / paging / lro / lropaging
methods)
- `SdkEnumValueType`
### Population
- `createSdkClientType` (clients.ts): populates `isExactName` via
`isExactClientName(...)` and normalizes the override so the internal
`_exact_:` marker no longer leaks into `SdkClientType.name`.
- `getSdkBasicServiceMethod` (methods.ts): populates `isExactName`;
spread by all method variants.
- `getSdkEnumValueWithDiagnostics` and `getSdkUnionEnumValues`
(types.ts): populate `isExactName` for both enum and union-as-enum
members.
### Example
```tsp
#suppress "experimental-feature" "using exact"
@@clientName(MyService, exact("my_exact_client"));
@@clientName(MyService.testOp, exact("my_exact_op"));
@@clientName(MyService.Status.Active, exact("my_active_value"));
```
All three resulting SDK types now expose `isExactName: true` with their
`name` returned verbatim (no `_exact_:` prefix).
### Tests
Extended `test/functions/exact.test.ts` with cases covering clients,
methods, and enum values; existing method test now also asserts
`isExactName`.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: tadelesh <1726438+tadelesh@users.noreply.github.com>
Co-authored-by: Chenjie Shi <tadelesh.shi@live.cn>
…perties (#4487) JSON `number` values in example files were silently dropped for properties typed as `decimal` or `decimal128` (e.g. `threshold: decimal` with example value `80`), so they never appeared in the example value set surfaced by TCGC. `getSdkTypeExample` in `packages/typespec-client-generator-core/src/example.ts` routed examples to the numeric branch only for `isSdkIntKind` / `isSdkFloatKind`. Fixed-point kinds (`decimal`, `decimal128`) belong to `SdkFixedPointKindsEnum` and fell through the `switch`, yielding `undefined`. ### Changes - **`interfaces.ts`**: Export the existing `isSdkFixedPointKind` predicate. - **`example.ts`**: Include `isSdkFixedPointKind(type.kind)` in the numeric dispatch so `decimal`/`decimal128` are handled like other numerics. - **Tests**: Added `SdkNumberExample for decimal` and `SdkNumberExample for decimal128` cases with corresponding fixture JSON files. ```ts // Before if (isSdkIntKind(type.kind) || isSdkFloatKind(type.kind)) { return getSdkBaseTypeExample("number", type, example, relativePath); } // After if (isSdkIntKind(type.kind) || isSdkFloatKind(type.kind) || isSdkFixedPointKind(type.kind)) { return getSdkBaseTypeExample("number", type, example, relativePath); } ``` --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: tadelesh <1726438+tadelesh@users.noreply.github.com>
…lue is from a child model (#4484) When an example is given for a model with subtypes introduced via `@Legacy.hierarchyBuilding` (e.g. `Dog` rebased under `Pet`), example values whose discriminator points to such a subtype (e.g. `kind: "dog"` on a body typed as `Pet`) were silently dropped from the parsed example output. ### Root Cause `updateSerializationOptions` is computed and applied before `handleLegacyHierarchyBuilding` runs. When `@hierarchyBuilding` rebases a model (e.g. `Dog`) under a new base (e.g. `Pet`) and registers it in `discriminatedSubtypes`, the newly added subtype's properties never get serialization options populated. The example resolution code in `example.ts` looks up properties by `serializationOptions.json.name` — because that field is missing on the rebased subtype, the lookup silently fails and the example values are dropped. ### Fix `src/types.ts`: After `handleLegacyHierarchyBuilding` adds a subtype to its new base's `discriminatedSubtypes`, call a new `propagateSerializationToSubtype()` helper. It walks up the base model chain to find the nearest ancestor with computed serialization options, then invokes `updateSerializationOptions` on the new subtype with the matching content types so its properties receive `serializationOptions.json` / `.xml` as they would have if it had been part of the hierarchy when serialization options were first computed. ### Test `test/examples/types.test.ts`: Added a test that uses `@@Usage(Animal, Usage.input | Usage.output)` (matching the real-world pattern) with `@@Legacy.hierarchyBuilding(Dog, Pet)`, an example whose body has `kind: "dog"`, and asserts that both `kind` and the `Dog`-only `breed` property are preserved in the parsed example. - [x] Identify root cause (serialization options not propagated to subtypes added by `@hierarchyBuilding`) - [x] Add `propagateSerializationToSubtype()` in `src/types.ts` - [x] Add test using real-world `@@Usage(Animal)` pattern - [x] Add changelog entry - [x] Verify all tests pass --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: tadelesh <1726438+tadelesh@users.noreply.github.com>
Hotfix release for `@azure-tools/typespec-client-generator-core` 0.69.0 ## Changes - [#4480] Extend `isExactName` to clients, methods, and enum values - [#4477] Fix `reorderParameters`/`addParameter`/`removeParameter`/`replaceParameter` decorator application on cloned types - [#4487] Fix example value matching for `decimal`/`decimal128` properties - [#4484] Fix example values dropped on subtypes added via `@hierarchyBuilding` ## Checklist - [x] Version bump via `pnpm chronus version --ignore-policies` - [x] Only TCGC package changed - [x] Core submodule pointer unchanged --------- Co-authored-by: tadelesh <chenjieshi@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ibrary (#4501) `validateMultipleServiceDependencyVersions` (added with the `inconsistent-multiple-service-dependency` warning) crashed with `TypeError: Cannot read properties of undefined (reading 'value')` whenever `resolveVersions` returned an entry mapping a dependency namespace to `undefined` — which happens when the merged service's latest version has no `@useDependency` mapping for that library. ### Changes - **`packages/typespec-client-generator-core/src/decorators.ts`**: when the resolved `depVersion` is `undefined`, fall back to the latest version of the depended library via `getVersion(program, depNs).getVersions()`, matching what downstream emitters pick. Skip the entry only if the dependency namespace itself has no versions. - **Test**: regression test in `test/clients/structure.test.ts` covering a service whose latest enum member lacks `@useDependency`; reproduces the crash on `main` and verifies the fallback resolves to the same version as the sibling service (no spurious warning). ### Repro ```tsp @versioned(LibVersions) namespace SharedLib { enum LibVersions { v1, v2 } } @service @versioned(VersionsA) namespace ServiceA { enum VersionsA { @useDependency(SharedLib.LibVersions.v2) av1 } op a(): void; } @service @versioned(VersionsB) namespace ServiceB { enum VersionsB { @useDependency(SharedLib.LibVersions.v2) bv1, bv2, // latest, no @useDependency -> SharedLib resolves to undefined } op b(): void; } @client({ name: "CombineClient", service: [ServiceA, ServiceB], autoMergeService: true }) namespace CombineClient {} ``` --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: tadelesh <1726438+tadelesh@users.noreply.github.com> Co-authored-by: Chenjie Shi <tadelesh.shi@live.cn>
…s model variants (#4508) ## Problem PR #4440 rewrote `listOrphanTypes` to iterate via `listScopedDecoratorData(context, usageKey)`, which follows **decorator application order**. The old code walked namespaces and iterated **models first, then enums, then unions**. This ordering matters because anonymous types (e.g. anonymous model variants inside unions) get their generated name from whichever context processes them first. When `@@usage` on a union appears before `@@usage` on a model that references it, the anonymous variant gets named from the union context (e.g. `RecursiveNullableType1`) instead of the model property context (e.g. `OuterWithNullableValue`). Reported via Azure/typespec-rust#969 — upgrading from TCGC 0.68.0 to 0.68.2 renamed `OuterWithNullableValue` → `RecursiveNullableType1`. ## Fix Collect orphan types into three separate buckets (models, enums, unions) and concatenate them at the end: `[...models, ...enums, ...unions]`. This restores the models-first ordering while preserving the #4440 improvement of discovering types from imported libraries. ## Testing Added a regression test that reproduces the exact scenario from the typespec-rust spec. Co-authored-by: iscai-msft <isabellavcai@gmail.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Per-language `@clientLocation` (and `@clientName`) overrides produce a
different resolved `operationId` for each language emitter, but example
files from `azure-rest-api-specs` carry a single canonical `operationId`
(the autorest-resolved one). The previous matcher in
`handleClientExamples` always resolved under the current emitter's
scope, so any language whose group differed from the example file
silently lost example linkage — with no diagnostic and no generated
sample.
```tsp
@@clientLocation(TagsResources.deleteAtScope, "Tags", "!javascript");
@@clientLocation(TagsResources.deleteAtScope, "TagsOperations", "javascript");
```
Example file: `{ "operationId": "Tags_DeleteAtScope" }` — matched for
non-JS, lost for JS.
### Changes
- **`example.ts` — match under the `autorest` scope.** In
`handleClientExamples`, build a shallow-cloned context (`{ ...context,
emitterName: "autorest" }`) and pass it to both `resolveOperationId`
attempts (with and without renaming). The rest of the pipeline
(`handleMethodExamples`, etc.) still uses the original context, so only
the lookup key changes.
- **Regression test.** New case in `test/examples/load.test.ts` with
conflicting `@clientLocation(AnotherInterface, "!javascript")` /
`@clientLocation("JsGroup", "javascript")`, run under the JS emitter,
asserting the JS-relocated method still links to the autorest-keyed
example file. Verified the test fails on `main` and passes with the fix.
- **Changelog.** `fix` entry under `.chronus/changes/`.
### Semantics
- `@clientLocation`/`@clientName` declared with no scope or with the
`autorest` scope continue to drive example matching (autorest scope sees
them) — existing tests unchanged.
- Per-language scoped overrides (positive or negated) no longer affect
example matching, so a single `operationId` in the example file links
across all languages.
- Behavior for `@operationId` is unchanged (it short-circuits inside
`resolveOperationId`).
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: tadelesh <1726438+tadelesh@users.noreply.github.com>
… types (#4514) For an `Http.File<"a" | "b">` request body, the synthetic `contentType` parameter referenced an enum (e.g. `UploadFileMultipleContentTypesContentType`) that did not appear in `sdkPackage.enums` — the package instead contained a separately generated `FileContentType` / `FileContentType2` for the File model's `contentType` property. Two distinct `SdkEnumType` instances were being produced for the same logical type. Still reproduces on 0.68.3. ### Root cause `createContentTypeOrAcceptHeader` synthesized a fresh `Union` via `tk.union.create(...)` for the multi-content-type request case, bypassing the existing union already attached to the File model's `contentType` property. As a result two `SdkEnumType` instances were created from two different `Union` cache keys. ### Changes - **`src/types.ts`** — In `updateTypesFromOperation`, when the body is a file body with more than one content type, pre-warm `__referencedTypeCache` for `httpBody.contentTypeProperty.type` under the operation naming context (pushing `"ContentType"`) before the File model itself is processed. This ensures the cached `SdkEnumType` is named after the operation (e.g. `UploadFileMultipleContentTypesContentType`) rather than after the File model. - **`src/http.ts`** — When the body is a file body (`httpOperation.parameters.body?.bodyKind === "file"`), reuse `body.contentTypeProperty.type` instead of synthesizing a new union, so `getClientType` returns the same cached `SdkEnumType` instance used by the File model. Combined with the pre-warm above, the synthetic `contentType` header parameter and the File model's `contentType` property end up referencing one and the same enum, which is present in `sdkPackage.enums` with the operation-prefixed name. - **`test/methods/file.test.ts`** — Update the multi-content-type test to assert the operation-prefixed name (`UploadFileMultipleContentTypesContentType`) and that the parameter's enum is identity-equal to an entry in `sdkPackage.enums`. - **`.chronus/changes/…`** — Fix changelog entry. ```ts // types.ts (updateTypesFromOperation, before processing the body) if ( httpBody.bodyKind === "file" && httpBody.contentTypes.length > 1 && httpBody.contentTypeProperty.type.kind === "Union" ) { pushNamingContext(context, "ContentType", undefined); diagnostics.pipe( getClientTypeWithDiagnostics(context, httpBody.contentTypeProperty.type, operation), ); popNamingContext(context); } ``` ```ts // http.ts (request, contentTypes.length > 1) const fileBody = bodyObject.kind === "body" && httpOperation.parameters.body?.bodyKind === "file" ? httpOperation.parameters.body : undefined; const contentTypePropertyType = fileBody?.contentTypeProperty.type; if (contentTypePropertyType && contentTypePropertyType.kind === "Union") { type = getClientType(context, contentTypePropertyType, httpOperation.operation); } else { const union = tk.union.create( bodyObject.contentTypes.map((ct) => tk.literal.createString(ct)), ); type = getClientType(context, union, httpOperation.operation); } ``` Non-file bodies and the response (`accept`) path are unchanged. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: tadelesh <1726438+tadelesh@users.noreply.github.com> Co-authored-by: tadelesh <chenjieshi@microsoft.com> Co-authored-by: Chenjie Shi <tadelesh.shi@live.cn>
Hotfix release for `@azure-tools/typespec-client-generator-core` 0.68.4 ## Changes - [#4515] Fix TCGC example matching for per-language `@clientLocation` - [#4514] Fix mismatched enum for `Http.File` body with multiple content types ## Checklist - [x] Version bump via `pnpm chronus version --ignore-policies` - [x] Only TCGC package changed - [x] Core submodule pointer unchanged Co-authored-by: tadelesh <chenjieshi@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
tadelesh
requested review from
bterlson,
iscai-msft,
joheredi,
lmazuel,
m-nash,
markcowl,
srnagar and
timotheeguerin
as code owners
microsoft-github-policy-service
Bot
added
eng
emitter:python
Collaborator
|
❌ There is undocummented changes. Run The following packages have changes but are not documented.
Show changes |
Member
Author
|
@copilot Revert the change of |
Co-authored-by: tadelesh <1726438+tadelesh@users.noreply.github.com>
Contributor
Done. The |
msyyc
approved these changes
Jun 2, 2026
commit: |
Contributor
⚡ Benchmark Results
Full details – comparing
|
| Metric | Baseline | Current | Change |
|---|---|---|---|
| total | 🔴 6.35s | 🔴 6.22s | -2.1% |
| loader | 🟡 202.6ms | 🟢 174.3ms | -14.0% 🟢 |
| resolver | 🟢 16.6ms | 🟢 16.1ms | -3.5% |
| checker | 🟢 176.1ms | 🟢 182.5ms | +3.6% |
| validation | 🟢 40.5ms | 🟢 43.2ms | +6.8% 🔴 |
| ↳ validation/@azure-tools/typespec-azure-core | 🟢 5.9ms | 🟢 6.4ms | +9.2% |
| ↳ validation/@typespec/http | 🟢 4.8ms | 🟢 5.1ms | +6.9% |
| ↳ validation/@typespec/rest | 🟢 0.5ms | 🟢 0.5ms | +3.5% |
| ↳ validation/@typespec/versioning | 🔴 27.6ms | 🔴 28.9ms | +4.8% |
| ↳ validation/compiler | 🟢 1.4ms | 🟢 1.4ms | -1.4% |
| linter | 🟢 123.7ms | 🟢 162.2ms | +31.1% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/auth-required | 🟢 0.0ms | 🟢 0.0ms | +15.3% |
| ↳ linter/@azure-tools/typespec-azure-core/bad-record-type | 🟢 0.2ms | 🟢 0.3ms | +15.7% |
| ↳ linter/@azure-tools/typespec-azure-core/byos | 🟢 5.4ms | 🟢 7.4ms | +36.2% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/casing-style | 🟢 0.6ms | 🟢 0.7ms | +22.2% |
| ↳ linter/@azure-tools/typespec-azure-core/composition-over-inheritance | 🟢 0.1ms | 🟢 0.1ms | -2.5% |
| ↳ linter/@azure-tools/typespec-azure-core/documentation-required | 🟢 0.8ms | 🟢 0.9ms | +21.4% |
| ↳ linter/@azure-tools/typespec-azure-core/friendly-name | 🟢 0.6ms | 🟢 0.7ms | +15.2% |
| ↳ linter/@azure-tools/typespec-azure-core/key-visibility-required | 🟢 0.1ms | 🟢 0.2ms | +4.6% |
| ↳ linter/@azure-tools/typespec-azure-core/known-encoding | 🟢 0.3ms | 🟢 0.3ms | +3.0% |
| ↳ linter/@azure-tools/typespec-azure-core/long-running-polling-operation-required | 🟢 0.3ms | 🟢 0.3ms | +0.9% |
| ↳ linter/@azure-tools/typespec-azure-core/no-case-mismatch | 🟢 0.2ms | 🟢 0.2ms | -1.1% |
| ↳ linter/@azure-tools/typespec-azure-core/no-closed-literal-union | 🟢 0.2ms | 🟢 0.3ms | +7.4% |
| ↳ linter/@azure-tools/typespec-azure-core/no-enum | 🟢 0.0ms | 🟢 0.0ms | -1.5% |
| ↳ linter/@azure-tools/typespec-azure-core/no-error-status-codes | 🟢 0.1ms | 🟢 0.1ms | +2.9% |
| ↳ linter/@azure-tools/typespec-azure-core/no-explicit-routes-resource-ops | 🟢 0.1ms | 🟢 0.1ms | +9.8% |
| ↳ linter/@azure-tools/typespec-azure-core/no-format | 🟢 0.5ms | 🟢 0.8ms | +45.9% |
| ↳ linter/@azure-tools/typespec-azure-core/no-generic-numeric | 🟢 0.4ms | 🟢 0.4ms | -6.6% |
| ↳ linter/@azure-tools/typespec-azure-core/no-header-explode | 🟡 17.8ms | 🔴 23.0ms | +28.9% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/no-legacy-usage | 🟢 1.1ms | 🟢 1.4ms | +27.1% |
| ↳ linter/@azure-tools/typespec-azure-core/no-multiple-discriminator | 🟢 0.1ms | 🟢 0.1ms | -0.1% |
| ↳ linter/@azure-tools/typespec-azure-core/no-nullable | 🟢 0.2ms | 🟢 0.3ms | +15.4% |
| ↳ linter/@azure-tools/typespec-azure-core/no-offsetdatetime | 🟢 1.1ms | 🟢 1.3ms | +17.0% |
| ↳ linter/@azure-tools/typespec-azure-core/no-openapi | 🟢 2.2ms | 🟢 2.4ms | +6.2% |
| ↳ linter/@azure-tools/typespec-azure-core/no-private-usage | 🟢 1.7ms | 🟢 2.0ms | +17.4% |
| ↳ linter/@azure-tools/typespec-azure-core/no-query-explode | 🟡 17.6ms | 🔴 23.3ms | +32.4% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/no-response-body | 🔴 21.9ms | 🔴 35.5ms | +62.3% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/no-rest-library-interfaces | 🟢 0.0ms | 🟢 0.0ms | +9.5% |
| ↳ linter/@azure-tools/typespec-azure-core/no-route-parameter-name-mismatch | 🟢 4.4ms | 🟢 6.5ms | +47.3% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/no-rpc-path-params | 🟢 0.2ms | 🟢 0.2ms | +9.6% |
| ↳ linter/@azure-tools/typespec-azure-core/no-string-discriminator | 🟢 0.0ms | 🟢 0.0ms | -0.9% |
| ↳ linter/@azure-tools/typespec-azure-core/no-unknown | 🟢 0.2ms | 🟢 0.2ms | +20.6% |
| ↳ linter/@azure-tools/typespec-azure-core/no-unnamed-union | 🟢 0.3ms | 🟢 0.4ms | +20.4% |
| ↳ linter/@azure-tools/typespec-azure-core/operation-missing-api-version | 🟢 0.2ms | 🟢 0.2ms | +10.8% |
| ↳ linter/@azure-tools/typespec-azure-core/request-body-problem | 🟢 0.3ms | 🟢 0.3ms | +6.0% |
| ↳ linter/@azure-tools/typespec-azure-core/require-versioned | 🟢 0.0ms | 🟢 0.0ms | -1.9% |
| ↳ linter/@azure-tools/typespec-azure-core/response-schema-problem | 🔴 20.7ms | 🔴 26.5ms | +27.8% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/rpc-operation-request-body | 🟢 0.3ms | 🟢 0.5ms | +65.7% |
| ↳ linter/@azure-tools/typespec-azure-core/spread-discriminated-model | 🟢 0.3ms | 🟢 0.3ms | +11.7% |
| ↳ linter/@azure-tools/typespec-azure-core/use-standard-names | 🟢 4.7ms | 🟢 6.7ms | +43.5% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/use-standard-operations | 🟢 0.1ms | 🟢 0.1ms | +11.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-common-types-version | 🟢 3.5ms | 🟢 3.7ms | +4.7% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-custom-resource-no-key | 🟢 0.1ms | 🟢 0.1ms | +6.4% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-custom-resource-usage-discourage | 🟢 0.1ms | 🟢 0.1ms | +6.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-delete-operation-response-codes | 🟢 4.6ms | 🟢 4.7ms | +1.4% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-no-path-casing-conflicts | 🟢 3.9ms | 🟢 4.1ms | +4.9% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-no-record | 🟢 0.3ms | 🟢 0.4ms | +9.5% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-post-operation-response-codes | 🟢 0.4ms | 🟢 0.4ms | +8.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-put-operation-response-codes | 🟢 0.0ms | 🟢 0.0ms | +2.1% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-action-no-segment | 🟢 0.2ms | 🟢 0.2ms | +13.8% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-duplicate-property | 🟢 0.1ms | 🟢 0.1ms | -2.6% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-interface-requires-decorator | 🟢 0.0ms | 🟢 0.0ms | +11.8% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-invalid-action-verb | 🟢 0.1ms | 🟢 0.1ms | +12.9% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-invalid-envelope-property | 🟢 0.1ms | 🟢 0.1ms | +3.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-invalid-version-format | 🟢 0.0ms | 🟢 0.0ms | +0.7% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-key-invalid-chars | 🟢 0.2ms | 🟢 0.2ms | +1.6% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-name-pattern | 🟢 0.0ms | 🟢 0.0ms | -2.1% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-operation | 🟢 0.2ms | 🟢 0.2ms | -0.3% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-operation-response | 🟢 4.1ms | 🟢 4.4ms | +5.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-patch | 🟢 0.3ms | 🟢 0.3ms | +9.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-path-segment-invalid-chars | 🟢 0.2ms | 🟢 0.2ms | +4.1% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-provisioning-state | 🟢 0.1ms | 🟢 0.1ms | +13.2% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/beyond-nesting-levels | 🟢 0.1ms | 🟢 0.1ms | +5.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/empty-updateable-properties | 🟢 0.1ms | 🟢 0.1ms | -2.4% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/improper-subscription-list-operation | 🟢 0.0ms | 🟢 0.0ms | +0.5% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/lro-location-header | 🟡 12.4ms | 🟡 12.9ms | +4.4% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/missing-operations-endpoint | 🟢 0.0ms | 🟢 0.0ms | +3.3% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/missing-x-ms-identifiers | 🟢 0.2ms | 🟢 0.3ms | +8.2% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/no-empty-model | 🟢 0.1ms | 🟢 0.1ms | +4.7% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/no-resource-delete-operation | 🟢 0.2ms | 🟢 0.2ms | -5.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/no-response-body | 🟡 19.4ms | 🔴 20.4ms | +5.1% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/patch-envelope | 🟢 0.1ms | 🟢 0.1ms | -1.9% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/resource-name | 🟢 0.1ms | 🟢 0.1ms | -2.1% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/secret-prop | 🟢 2.1ms | 🟢 2.2ms | +5.2% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/unsupported-type | 🟢 0.3ms | 🟢 0.3ms | +4.2% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/version-progression | 🟢 0.0ms | 🟢 0.0ms | -1.7% |
| ↳ linter/@azure-tools/typespec-client-generator-core/property-name-conflict | 🟢 1.0ms | 🟢 1.1ms | +6.6% |
| ↳ linter/@azure-tools/typespec-client-generator-core/require-client-suffix | 🟢 0.2ms | 🟢 0.2ms | +1.8% |
| emit | 🔴 5.75s | 🔴 5.56s | -3.3% |
| ↳ emit/@azure-tools/typespec-autorest | 🟢 198.9ms | 🟢 195.8ms | -1.5% |
| ↳ emit/@azure-tools/typespec-python | 🔴 4.24s | 🔴 4.04s | -4.6% |
| ↳ emit/@typespec/http-client-js | 🔴 1.06s | 🔴 1.12s | +5.3% 🔴 |
| ↳ emit/@typespec/openapi3 | 🟢 139.5ms | 🟢 147.9ms | +6.1% 🔴 |
| ↳ emit/@typespec/openapi3/compute | 🟢 123.2ms | 🟢 131.4ms | +6.7% 🔴 |
| ↳ emit/@typespec/openapi3/write | 🟢 16.4ms | 🟢 16.5ms | +0.6% |
Averaged across 3 specs (azure-arm-resource-manager, azure-core-dataplane, azure-full).
Threshold: changes > ±5% are highlighted.
🟢 Fast · 🟡 Moderate (stages >200ms, rules >10ms) · 🔴 Slow (stages >400ms, rules >20ms)
Collaborator
|
You can try these changes here
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.