feat(compiler): allow declarations to be used as expressions by timotheeguerin · Pull Request #11019 · microsoft/typespec

Timothee Guerin (timotheeguerin) · 2026-06-18T19:09:33Z

Summary

Allow model, enum, union, and scalar declarations to be used as expressions (e.g. the right-hand side of an alias, property types, return types, union variants).

In expression position these declarations:

are anonymous — their name is ""
produce a type with expression: true (so the type graph explicitly records that it came from an expression)
are not registered in the enclosing namespace

alias Foo = enum {
  a,
  b,
};

model Bar {
  status: enum { active, inactive };
  unit: scalar extends string;
  inner: model { x: string };
}

Named forms in expression position are also allowed (e.g. nested: model Inner { x: string }), and declarations can be nested.

Motivation

A model/enum/scalar is often only meaningful in the context of its parent type. Allowing them inline lets a spec be expressed more clearly without polluting the namespace with single-use declarations. Specifically this enables:

Naming sub-types for clarity & emitters — a name like model Inner { ... } documents intent and gives emitters a usable name, even though the declaration is not registered or referenceable.
A path to decorating expressions (follow-up) — the keyword forms carry a decorators field; a later PR can allow @doc("...") model Inner { ... } in expression position.
Passing inline values to decorators when the type doesn't need to exist outside that use.

All four data-shape declarations are supported for consistency. interface, op, and alias are intentionally excluded — an anonymous interface/op has no meaningful use as a type expression.

Approach

Rather than introducing new *Expression AST node kinds, the existing statement node kinds are reused with an optional id (OptionallyNamedDeclarationNode), and these kinds are added to the Expression union. Whether a declaration is in statement vs expression position is determined by its parent node kind.

types.ts — OptionallyNamedDeclarationNode (optional id); expression: boolean on Model/Enum/Scalar (Union already had it); the 4 statement kinds added to the Expression union.
parser.ts — optional-id parsing on the 4 declaration parsers; parsePrimaryExpression dispatch for the model/enum/union/scalar keywords; a scalar in expression position no longer consumes the alias trailing ;.
binder.ts — anonymous ("-" symbol) vs named binding depending on position.
checker.ts — derive name/expression; skip namespace registration for expression-form types; route expression decls through the namespace walk-up in getParentNamespaceType; new templated-declaration-in-expression diagnostic.
formatter — optional-id printing; avoids a double ; for anonymous scalars.
server/inspector — null-safe handling of the now-optional id.

Semantics of the `expression` flag

expression means "produced in expression position / not registered as a named statement" — it is position-based, not name-based. A named declaration expression (model Inner { ... } used as a property type) is therefore expression: true even though it has a name. This is the single definition all consumers should rely on.

Diagnostics

Template parameters on a declaration in expression position are rejected (templated-declaration-in-expression) since an anonymous declaration cannot be referenced or instantiated.

Tests

test/checker/declaration-expressions.test.ts (14 tests)
test/parser.test.ts — new "declaration expressions" block (11 cases)
test/formatter/formatter.test.ts — new "declaration expressions" block (5 cases)

Full compiler suite: 3982 passed / 6 skipped. tsc --noEmit, pnpm format, and pnpm lint are all clean.

Follow-ups (not in this PR)

Decorating declaration expressions. Feasible and grammar-unambiguous only if the @ handling in parsePrimaryExpression is narrowly relaxed to "decorators immediately followed by a declaration keyword" (keyword-only — do not broaden to arbitrary expressions). Decorators attach to the keyword-form node.
Naming policy (open question). A name on a pure-expression declaration is kept on Type.name but is not referenceable. Whether it should ever be bindable is still undecided.
Audit consumers of the expression flag (expression = "produced in expression position / not registered as a named statement"):
- packages/openapi/src/helpers.ts shouldInline → inline when type.expression (else anonymous scalars emit empty-named declarations and named expressions are hoisted as collision-prone components).
- packages/versioning/src/validate.ts union-variant branch → gate on SyntaxKind.UnionExpression, not expression (keyword-form union variants can have decorators).
- Typekit: align kits/enum.ts (expression: false) with kits/model.ts (name === undefined).
- Verify json-schema emitter inline path for anonymous enum/scalar.
Deeper TextMate grammar rules specific to keyword-declarations in expression position.
Compat note: Declaration now admits an optional id (public type) — minor downstream typing impact.

Allow model, enum, union, and scalar declarations to be used in expression position (e.g. alias RHS, property types). In expression position they are anonymous (name is "") and the resulting type has expression: true; they are not registered in the enclosing namespace. A diagnostic is reported when template parameters are used on a declaration in expression position.

pkg-pr-new · 2026-06-18T19:11:07Z

Open in StackBlitz

@typespec/compiler

npm i https://pkg.pr.new/@typespec/compiler@11019

@typespec/graphql

npm i https://pkg.pr.new/@typespec/graphql@11019

@typespec/html-program-viewer

npm i https://pkg.pr.new/@typespec/html-program-viewer@11019

@typespec/json-schema

npm i https://pkg.pr.new/@typespec/json-schema@11019

@typespec/openapi

npm i https://pkg.pr.new/@typespec/openapi@11019

@typespec/openapi3

npm i https://pkg.pr.new/@typespec/openapi3@11019

@typespec/versioning

npm i https://pkg.pr.new/@typespec/versioning@11019

commit: 9076246

github-actions · 2026-06-18T19:12:23Z

All changed packages have been documented.

✅ @typespec/compiler
✅ @typespec/graphql
✅ @typespec/html-program-viewer
✅ @typespec/json-schema
✅ @typespec/openapi
✅ @typespec/openapi3
✅ @typespec/versioning

Show changes

`@typespec/compiler` - feature ✏️

Allow model, enum, union, and scalar declarations to be used as expressions. A declaration used in expression position has its corresponding type marked with expression: true and is not registered in the enclosing namespace. It may be named or anonymous (in which case it has no name).,> ,> This is an experimental feature that must be opted into by adding declaration-expressions to the features list in tspconfig.yaml; using a declaration expression without it reports a declaration-expression-disabled error.,> ,> They can be used anywhere an expression is expected, including aliases, model properties, decorator arguments, template arguments, function/call arguments, and tuples.,> ,> model, scalar, and union declaration expressions support the same extends clause as their statement form (union extends additionally requires the union-extends feature).,> ,> tsp,> alias Foo = enum {,> a,,> b,,> };,> ,> model Bar {,> status: enum { active, inactive };,> unit: scalar extends string;,> inner: model Inner { x: string };,> },> ,> @Versioning.versioned(enum Versions { v1, v2 }),> namespace MyService;,>

`@typespec/compiler` - feature ✏️

Allow decorators to be applied to model, enum, union, and scalar declarations used in expression position. Inline decorators can be applied directly, and augment decorators (@@) can target them through a navigation reference (such as ::type).,> ,> tsp,> model Foo {,> status: @doc("the current status") enum { active, inactive };,> inner: @doc("nested model") model Inner { x: string };,> },> ,> @@doc(Foo.status::type, "the current status");,>

`@typespec/compiler` - feature ✏️

Allow a doc comment to be applied inline to a model, enum, union, or scalar declaration expression, just like an inline @doc decorator.,> ,> tsp,> model Foo {,> status: /** the current status */ enum { active, inactive };,> },>

`@typespec/compiler` - feature ✏️

Improve formatting of declaration expressions (model, enum, union, and scalar used in expression position) that carry doc comments and/or decorators. When the inline form would exceed the print width, the doc comments and decorators are now each placed on their own line and the whole block is indented one level instead of overflowing.,> ,> tsp,> model Foo {,> status:,> @summary("a fairly long summary text here"),> @example("some-default-example-value"),> enum {,> active,,> inactive,,> };,> },>

`@typespec/json-schema` - feature ✏️

Support model, enum, union, and scalar declarations used in expression position. Anonymous declaration expressions are inlined, while named ones are hoisted into their own schema.,> ,> tsp,> model Foo {,> status: enum { active, inactive }; // inlined,> unit: scalar extends string; // inlined,> inner: model Inner { x: string }; // hoisted as `Inner.json`,> },>

`@typespec/openapi` - feature ✏️

Support model, enum, union, and scalar declarations used in expression position. Anonymous declaration expressions are inlined, while named ones are hoisted into a referenced component.,> ,> tsp,> model Foo {,> status: enum { active, inactive }; // inlined,> unit: scalar extends string; // inlined,> inner: model Inner { x: string }; // hoisted as component `Inner`,> },>

`@typespec/openapi3` - feature ✏️

Support model, enum, union, and scalar declarations used in expression position. Anonymous declaration expressions are inlined, while named ones are hoisted into a referenced component.,> ,> tsp,> model Foo {,> status: enum { active, inactive }; // inlined,> unit: scalar extends string; // inlined,> inner: model Inner { x: string }; // hoisted as component `Inner`,> },>

`@typespec/compiler` - feature ✏️

$.enum.create now produces an enum expression (expression: true) when given an empty name, mirroring $.model.create.

`@typespec/versioning` - feature ✏️

Validate the variants of a keyword-form union expression (union { ... }) used in expression position like the variants of a named union, so versioning incompatibilities on decorated variants are reported.

`@typespec/graphql` - fix ✏️

Set the required expression field to false when creating a replacement scalar so scalars produced by the model mutation engine are valid declaration types.

`@typespec/html-program-viewer` - feature ✏️

Display the new expression property on Model, Enum, and Scalar types in the program viewer.

…erty

…r tests

…g naming

azure-sdk-automation · 2026-06-18T19:41:25Z

You can try these changes here

🛝 Playground	🌐 Website	🛝 VSCode Extension

A keyword-form union (`union { a, b }`) used in expression position is marked `expression: true`, which caused checkUnionExpression to flatten its (possibly named) variants into the parent union, silently dropping colliding members. Flatten only unions originating from the `|` operator (UnionExpression node).

Add tests for: - expression: false on statement declarations - name retention on named declaration expressions - named expressions not being referenceable - union namespace non-registration - alias-resolved types, op return/param, union variant usage - member access via alias, decorator rejection - enum values, union named variants, scalar constructors, model spread - parser negatives for interface/op in expression position - formatter named & nested declaration expressions

Anonymous declarations used in expression position rendered with a stray namespace prefix (e.g. `Ns.` for enum/scalar, `Ns.{ x: string }` for keyword-form model). Render them inline and un-prefixed, mirroring union expression naming. Also extract a single shared `isDeclarationInExpressionPosition` helper used by both the binder and checker so the two position predicates cannot drift, and add regression tests (type names, keyword-form union as `|` operand, template parameter referenced inside an expression declaration).

Inline anonymous declaration expressions and hoist named ones across the OpenAPI and JSON Schema emitters, validate keyword-form union expression variants in versioning, and derive the enum typekit `expression` flag from an empty name.

Timothee Guerin (timotheeguerin) · 2026-06-22T16:29:57Z

Follow-up: doc comments (and directives) are dropped on declaration expressions

Problem

Leading doc comments are not attached to declarations used in expression position. They are silently discarded:

model Foo {
  /** the status */
  status: enum { active, inactive };       // ✅ doc attaches to ModelProperty `status`
  other: /** the other */ enum { x, y };   // ❌ doc dropped entirely
}

alias E = /** my enum */ enum { a, b };    // ❌ doc dropped entirely

Verified against the AST: in the first case the doc node attaches to the ModelProperty; in the inline/alias cases no node receives the doc, so getDoc(program, type) returns undefined. The same applies to model, union, and scalar declaration expressions.

This is not specific to the inline-decorators work — it affects every declaration expression regardless of decorators — so it belongs to this base feature rather than the decorators PR.

Root cause

Doc comments take a separate parse path from decorators. They are scanned into docRanges as trivia and only materialized when something calls parseDocList(). That only happens inside parseAnnotations() and the statement-list loops.

Declaration expressions are parsed in parsePrimaryExpression (packages/compiler/src/core/parser.ts), whose model/enum/union/scalar keyword cases (and the @ decorator case) call parse*Statement(...) directly and never call parseDocList(). Any pending doc node sitting in docRanges is therefore thrown away.

For reference, at statement position docs/directives are attached after parsing via the mutate pattern, not passed into parse*Statement:

// parseTypeSpecScriptItemList / parseStatementList
item = parseDeclaration(pos, decorators, docs, directives);
...
mutate(item).directives = directives;
mutate(item).docs = docs;

parse*Statement(pos, decorators, modifiers, allowAnonymous) does not accept docs/directives.

Suggested implementation

In parsePrimaryExpression, for the four declaration-keyword cases and the @-decorator case that dispatches to them:

Call parseDocList() to consume the pending doc ranges (the leading doc comment before the keyword is already in docRanges by the time we reach these cases).
After building the declaration node, attach docs with mutate(node).docs = docs (mirror the statement-list pattern).
Decide on directive support too. Directives (#suppress, etc.) hit the existing case Token.Hash in parsePrimaryExpression which currently calls reportInvalidDirective(directives, "expression"). If we want directives on declaration expressions, this needs the same dispatch treatment as the @ case; otherwise leave directives rejected and scope this to doc comments only (document the choice).

A cleaner alternative is to factor the doc/directive/decorator collection so the expression path reuses the same ordering logic as parseAnnotations() (which accepts docs, directives, and decorators in any order), then dispatch to the declaration parse and attach all three. Watch ordering cases like /** doc */ @dec enum {} and @dec /** doc */ enum {} — parseDecoratorList() scanning past the decorator will repopulate docRanges, so a naive single parseDocList() call may miss docs that appear after the decorators.

Checker

No checker change expected: node.docs is already consumed for model/enum/union/scalar nodes (doc comments work for these at statement position), so attaching the docs in the parser is sufficient for getDoc to pick them up.

Tests to add

packages/compiler/test/checker/declaration-expressions.test.ts: mirror the existing decorator tests — assert getDoc(program, type) returns the doc text for an anonymous enum expression, a named model expression, a union expression, and a scalar expression, in both the property-inline form (prop: /** d */ enum {...}) and the alias form. Add a combined case (/** d */ @doc("x") enum {...}) to lock in ordering.
packages/compiler/test/formatter/formatter.test.ts: add formatter cases ensuring a leading doc comment is preserved/printed correctly on each declaration-expression kind.

Repro snippet for quick verification

@test model Foo {
  inner: /** the inner */ model Inner { x: string };
}

Expected after fix: getDoc(program, Foo.properties.get("inner").type) === "the inner".

# Conflicts: # packages/compiler/src/formatter/print/printer.ts

Replace the flag-based design (statement nodes with optional id + position inference) with dedicated SyntaxKind nodes per declaration type: Model/Scalar/Union/EnumDeclarationExpression. The Type-level `expression` field is kept so emitters/versioning are unchanged.

Timothee Guerin (timotheeguerin) · 2026-06-25T19:15:18Z

Design meeting discussion

hoisting names up should be done but we might want to validate no conflicts
- error/warn?
using those expression in decorator @Versioning.versioned(enum Versions {v1, v2})
formatting with multiple decorators/doc comments

  b: 
    @doc("Model b doc")
    @doc("Model b doc")
    @doc("Model b doc")
    model NamedB {
      prop: string;
    };

make sure linting rule will handle those new nameless expression
how do we see that used in Azure.

…expressions Allow decorators to be applied inline to model/enum/union/scalar declarations used in expression position, and allow augment decorators (@@) to target them via navigation references (e.g. `Foo.x::type`).

…omments, and formatting Support using model/enum/union/scalar declaration expressions in expression-list positions (decorator arguments, template arguments, function/call arguments, tuples), apply doc comments inline like decorators, and keep multiple inline decorators inline when formatting. Also consolidate the per-commit decl-expr changesets into PR-level entries: one @typespec/compiler feature entry each for declaration expressions, decorators on declaration expressions, doc comments, and the $.enum.create typekit change.

@foo

- Parser: scope declaration-keyword list termination to element start so an unclosed expression list (e.g. @foo(model X {}) no longer swallows the following statement - Typekit: add optional expression flag to model/union/enum descriptors and key isExpresion/isExpression off type.expression - Printer: use isDeclarationExpressionNode instead of parent-position inference - Docs: add 'In expression position' sections to models, enums, unions, scalars

Replace the experimental-feature warning with a dedicated declaration-expression-disabled error and restore ScalarStatement in the node inspector switch.

# Conflicts: # packages/compiler/src/core/helpers/type-name-utils.ts # packages/compiler/test/core/cli/actions/info.test.ts # packages/compiler/test/server/completion.tspconfig.test.ts # packages/versioning/test/incompatible-versioning.test.ts

Copilot

🟡 Changes recommended

The spec grammar update for ModelDeclarationExpression doesn’t reflect the implemented model is Base (no-body) expression form and needs to be corrected to match compiler behavior.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Files reviewed: 60/60 changed files
Comments generated: 1
Review effort level: Lite

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Copilot

🔵 Needs a closer look

It introduces new language syntax/AST/type-graph semantics and touches multiple compiler subsystems and emitters, warranting final human review despite strong test coverage.

Review details

Files reviewed: 60/60 changed files
Comments generated: 0 new
Review effort level: Lite

# Conflicts: # grammars/typespec.json # packages/compiler/src/core/messages.ts # packages/compiler/src/core/parser.ts # packages/compiler/src/formatter/print/comment-handler.ts # packages/compiler/test/core/cli/actions/info.test.ts # packages/compiler/test/server/completion.tspconfig.test.ts # website/src/content/docs/docs/language-basics/unions.md

Copilot

🟡 Changes recommended

There are a couple of concrete correctness/doc issues in the updated TypeKit defaulting and tester compiler-options merging semantics that should be addressed before approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Files reviewed: 60/60 changed files
Comments generated: 3
Review effort level: Lite

- Preserve tester-level configFile (and features) when per-call compiler options provide their own configFile. - Treat an empty name as anonymous when defaulting `expression` in `$.model.create`, `$.union.create` and `$.enum.create`. - Clarify wording around anonymous declaration expressions having no name.

Copilot

🔵 Needs a closer look

It introduces broad Tier 0 language/type-graph changes across parser/binder/checker/formatter/emitters, requiring careful human verification of compatibility and downstream impact.

Review details

Files reviewed: 61/61 changed files
Comments generated: 3
Review effort level: Lite

Copilot

🔵 Needs a closer look

The new mergeCompilerOptions behavior can still drop tester-enabled features when a per-call configFile.features is present due to shallow merging.

Review details

Suppressed comments (1)

packages/compiler/src/testing/tester.ts:99

mergeCompilerOptions shallow-merges configFile, so if a per-call compilerOptions.configFile includes its own features array it will replace (and effectively drop) the tester instance’s default features, contradicting the function comment that per-call options shouldn’t drop enabled features.

  const configFile =
    base?.configFile && override?.configFile
      ? ({ ...base.configFile, ...override.configFile } as TypeSpecConfig)
      : (override?.configFile ?? base?.configFile);
  return { ...base, ...override, ...(configFile && { configFile }) };

Files reviewed: 62/62 changed files
Comments generated: 0 new
Review effort level: Lite

# Conflicts: # packages/compiler/src/formatter/print/printer.ts

Copilot

🟢 Approval recommended

The changes are broad but well-tested and consistent; the only noted issue is a minor misleading test comment wording.

Review details

Files reviewed: 62/62 changed files
Comments generated: 1
Review effort level: Lite

+/**
+ * Declaration expressions are an experimental feature gated behind the
+ * `declaration-expressions` compiler feature. Enable it for these tests so they
+ * exercise the feature without the experimental warning.
+ */


microsoft-github-policy-service Bot added the compiler:core Issues for @typespec/compiler label Jun 18, 2026

fix(html-program-viewer): configure rendering for new expression prop…

053d3ff

…erty

microsoft-github-policy-service Bot added the ui:type-graph-viewer label Jun 18, 2026

Timothee Guerin (timotheeguerin) added 2 commits June 18, 2026 15:19

test(compiler): use expect and flatten top-level describe in decl-exp…

0b7d1ea

…r tests

docs: add html-program-viewer changelog and clarify compiler changelo…

0ceaad6

…g naming

Timothee Guerin (timotheeguerin) added 6 commits June 18, 2026 15:47

Add syntax highlighting for declarations in expression position

9c2aaf0

Update language spec grammar for declarations in expression position

8262855

microsoft-github-policy-service Bot added lib:openapi lib:versioning emitter:json-schema emitter:openapi3 Issues for @typespec/openapi3 emitter labels Jun 19, 2026

This was referenced Jun 19, 2026

feat(compiler): allow inline decorators on declaration expressions timotheeguerin/typespec#31

Closed

feat(compiler): allow inline decorators on declaration expressions #11035

Closed

Timothee Guerin (timotheeguerin) added 2 commits June 22, 2026 12:41

Merge remote-tracking branch 'upstream/main' into decl-expr

e3ecdd7

# Conflicts: # packages/compiler/src/formatter/print/printer.ts

Mark Cowlishaw (markcowl) mentioned this pull request Jun 25, 2026

[Design]: Uptake type declaration expressions in typespec-azure Azure/typespec-azure#4717

Open

Timothee Guerin (timotheeguerin) added 2 commits June 26, 2026 10:49

microsoft-github-policy-service Bot added the meta:website TypeSpec.io updates label Jun 26, 2026

iscai-msft approved these changes Aug 28, 2026

View reviewed changes

Comment thread .chronus/changes/decl-expr-openapi-inline-2026-4-18-0-0-1.md

Comment thread packages/compiler/test/checker/declaration-expressions.test.ts

Timothee Guerin (timotheeguerin) added 3 commits September 3, 2026 13:20

fix: gate declaration expressions behind feature flag error

7053830

Replace the experimental-feature warning with a dedicated declaration-expression-disabled error and restore ScalarStatement in the node inspector switch.

Merge remote-tracking branch 'origin/decl-expr' into decl-expr

8407316

Copilot AI review requested due to automatic review settings September 3, 2026 17:30

Copilot started reviewing on behalf of Timothee Guerin (timotheeguerin) September 3, 2026 17:31 View session

Copilot AI reviewed Sep 3, 2026

View reviewed changes

Comment thread packages/spec/src/spec.emu.html Outdated

Update ModelDeclarationExpression syntax for heritage

68a4502

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings September 3, 2026 17:45

Copilot started reviewing on behalf of Timothee Guerin (timotheeguerin) September 3, 2026 17:46 View session

Copilot AI reviewed Sep 3, 2026

View reviewed changes

Timothee Guerin (timotheeguerin) added 2 commits September 4, 2026 10:46

Merge remote-tracking branch 'origin/decl-expr' into decl-expr

35e2e7b

Copilot AI review requested due to automatic review settings September 4, 2026 14:47

Copilot started reviewing on behalf of Timothee Guerin (timotheeguerin) September 4, 2026 14:47 View session

Copilot AI reviewed Sep 4, 2026

View reviewed changes

Comment thread packages/compiler/src/testing/tester.ts Outdated

Comment thread packages/compiler/src/typekit/kits/model.ts

Comment thread packages/openapi/src/helpers.ts

Copilot AI review requested due to automatic review settings September 4, 2026 15:09

Copilot started reviewing on behalf of Timothee Guerin (timotheeguerin) September 4, 2026 15:09 View session

Copilot AI reviewed Sep 4, 2026

View reviewed changes

Comment thread packages/compiler/src/typekit/kits/enum.ts Outdated

Comment thread packages/compiler/src/typekit/kits/model.ts

Comment thread packages/compiler/src/typekit/kits/union.ts Outdated

fix: reject anonymous declarations in typekit create

df03591

Copilot AI review requested due to automatic review settings September 4, 2026 15:29

Copilot started reviewing on behalf of Timothee Guerin (timotheeguerin) September 4, 2026 15:29 View session

Copilot AI reviewed Sep 4, 2026

View reviewed changes

Mark Cowlishaw (markcowl) approved these changes Sep 4, 2026

View reviewed changes

Merge remote-tracking branch 'upstream/main' into decl-expr

9076246

# Conflicts: # packages/compiler/src/formatter/print/printer.ts

Copilot AI review requested due to automatic review settings September 5, 2026 00:15

Copilot started reviewing on behalf of Timothee Guerin (timotheeguerin) September 5, 2026 00:16 View session

Timothee Guerin (timotheeguerin) enabled auto-merge September 5, 2026 00:19

Copilot AI reviewed Sep 5, 2026

View reviewed changes

Uh oh!

Conversation

Timothee Guerin (timotheeguerin) commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Motivation

Approach

Semantics of the expression flag

Diagnostics

Tests

Follow-ups (not in this PR)

Uh oh!

pkg-pr-new Bot commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

@typespec/compiler - feature ✏️

@typespec/compiler - feature ✏️

@typespec/compiler - feature ✏️

@typespec/compiler - feature ✏️

@typespec/json-schema - feature ✏️

@typespec/openapi - feature ✏️

@typespec/openapi3 - feature ✏️

@typespec/compiler - feature ✏️

@typespec/versioning - feature ✏️

@typespec/graphql - fix ✏️

@typespec/html-program-viewer - feature ✏️

Uh oh!

azure-sdk-automation Bot commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Timothee Guerin (timotheeguerin) commented Jun 22, 2026

Follow-up: doc comments (and directives) are dropped on declaration expressions

Problem

Root cause

Suggested implementation

Checker

Tests to add

Repro snippet for quick verification

Uh oh!

Timothee Guerin (timotheeguerin) commented Jun 25, 2026

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🔵 Needs a closer look

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🔵 Needs a closer look

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🔵 Needs a closer look

Suppressed comments (1)

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟢 Approval recommended

Uh oh!

Reviewers

Assignees

Labels

Timothee Guerin (timotheeguerin) commented Jun 18, 2026 •

edited

Loading

Semantics of the `expression` flag

pkg-pr-new Bot commented Jun 18, 2026 •

edited

Loading

github-actions Bot commented Jun 18, 2026 •

edited

Loading

`@typespec/compiler` - feature ✏️

`@typespec/compiler` - feature ✏️

`@typespec/compiler` - feature ✏️

`@typespec/compiler` - feature ✏️

`@typespec/json-schema` - feature ✏️

`@typespec/openapi` - feature ✏️

`@typespec/openapi3` - feature ✏️

`@typespec/compiler` - feature ✏️

`@typespec/versioning` - feature ✏️

`@typespec/graphql` - fix ✏️

`@typespec/html-program-viewer` - feature ✏️

azure-sdk-automation Bot commented Jun 18, 2026 •

edited

Loading