<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>tsc-rs verified waves</title>
  <subtitle>Each verified change to the tsc-rs TypeScript compiler, with the test cases it gained.</subtitle>
  <link href="https://ts-rs.bext.dev/feed.xml" rel="self"/>
  <link href="https://ts-rs.bext.dev/progress"/>
  <id>https://ts-rs.bext.dev/progress</id>
  <updated>2026-09-27T00:00:00Z</updated>
  <author><name>tsc-rs</name></author>
  <entry>
    <title>comma-operator unused left side (TS2695) follows tsc exactly</title>
    <id>https://ts-rs.bext.dev/progress#wave-36</id>
    <link href="https://ts-rs.bext.dev/progress#wave-36"/>
    <updated>2026-09-27T00:00:36Z</updated>
    <summary>The side-effect test now mirrors tsc's isSideEffectFree. Identifiers, literals, templates, functions, arrows, classes, array and object literals, typeof, !x / +x / -x / ~x, non-null and JSX count as side-effect free. So do non-assigning binaries and conditionals when their parts are. Member access, this and void do not. The earlier list treated member access and this as side-effect free.</summary>
  </entry>
  <entry>
    <title>super in non-derived classes (TS2335) and computed keys (TS2466)</title>
    <id>https://ts-rs.bext.dev/progress#wave-35</id>
    <link href="https://ts-rs.bext.dev/progress#wave-35"/>
    <updated>2026-09-27T00:00:35Z</updated>
    <summary>TS2335: class members now mark their scope with whether their class has extends, taken from the AST (enclosing_class_derived), because nested and local classes don't resolve through class_info by name. super.x whose nearest container is a member of a non-derived class is TS2335. So is super() directly in such a class's constructor; elsewhere a super call is TS2337. TS2466: super in a computed property name with no enclosing super container. When an enclosing method exists, tsc resolves through it, as in a class expression inside a method.</summary>
  </entry>
  <entry>
    <title>property/accessor override kinds (TS2610 / TS2611)</title>
    <id>https://ts-rs.bext.dev/progress#wave-34</id>
    <link href="https://ts-rs.bext.dev/progress#wave-34"/>
    <updated>2026-09-27T00:00:34Z</updated>
    <summary>As in tsc's checkKindsOfPropertyMemberOverrides, overriding a base accessor with an instance property is now TS2610. Overriding a base property with an accessor is TS2611. The nearest base class declaring the member is found through the file's own class declarations. Ambiguous names and bases from other files are skipped. Private members, abstract base members, methods and auto-accessor fields (in either direction) are exempt, as in tsc. The error is on the derived member's first declaration. ClassInfo::accessor_props turned out to hold only accessor fields, so base kinds come from the AST. There are no false positives for either code in either full corpus.</summary>
  </entry>
  <entry>
    <title>multiple default exports (TS2528)</title>
    <id>https://ts-rs.bext.dev/progress#wave-33</id>
    <link href="https://ts-rs.bext.dev/progress#wave-33"/>
    <updated>2026-09-27T00:00:33Z</updated>
    <summary>TS2528 follows tsc's binder, which declares one default symbol. A new default declaration conflicts when its exclusions meet the symbol's flags:</summary>
  </entry>
  <entry>
    <title>await as a binding name (TS1262 / TS1359)</title>
    <id>https://ts-rs.bext.dev/progress#wave-32</id>
    <link href="https://ts-rs.bext.dev/progress#wave-32"/>
    <updated>2026-09-27T00:00:32Z</updated>
    <summary>The new await_bindings.rs reports binding names spelled await in await contexts, as tsc's parser does:</summary>
  </entry>
  <entry>
    <title>private names are lexically scoped (TS18013)</title>
    <id>https://ts-rs.bext.dev/progress#wave-31</id>
    <link href="https://ts-rs.bext.dev/progress#wave-31"/>
    <updated>2026-09-27T00:00:31Z</updated>
    <summary>x.#p is now TS18013 when no lexically enclosing class declares #p but the receiver's class declares it. For instances, a base class that declares it also counts, since a Derived instance carries Base's #p. For constructors it does not, because static private names aren't inherited; tsc reports TS2339 there. Non-static # accessors are now recorded as private instance members. There are no TS18013 false positives in either full corpus.</summary>
  </entry>
  <entry>
    <title>computed property name key types (TS2464)</title>
    <id>https://ts-rs.bext.dev/progress#wave-30</id>
    <link href="https://ts-rs.bext.dev/progress#wave-30"/>
    <updated>2026-09-27T00:00:30Z</updated>
    <summary>TS2464 now follows tsc's checkComputedPropertyName: the key's type must be string-, number- or symbol-like as a whole. Every union member must qualify, an intersection needs one qualifying member, and a type parameter is judged by its constraint (an unconstrained one fails). Types we cannot classify are accepted. Three exemptions match tsc: destructuring keys, [await] with no operand (tsc's error type), and the malformed mapped-type shape [K in T]: V on property signatures and class properties (tsc reports TS7061 there). There are no TS2464 false positives in either full corpus.</summary>
  </entry>
  <entry>
    <title>bare return; checked as undefined (TS2322)</title>
    <id>https://ts-rs.bext.dev/progress#wave-29</id>
    <link href="https://ts-rs.bext.dev/progress#wave-29"/>
    <updated>2026-09-27T00:00:29Z</updated>
    <summary>As in tsc's checkReturnStatement, a bare return; in a non-generator, non-constructor function whose declared return type excludes undefined (and is not void, any or unknown) is now TS2322, &quot;Type 'undefined' is not assignable...&quot;, at the return keyword under strictNullChecks. It adds no TS2322 false positives on bare-return lines in either full corpus.</summary>
  </entry>
  <entry>
    <title>value used as a type (TS2749)</title>
    <id>https://ts-rs.bext.dev/progress#wave-28</id>
    <link href="https://ts-rs.bext.dev/progress#wave-28"/>
    <updated>2026-09-27T00:00:28Z</updated>
    <summary>An identifier type reference to a name that the file declares only as a top-level value (var, let, const or function) is now TS2749. It applies when there is no same-named class, interface, alias, enum, namespace, import or global type, and no type parameter or nested type declaration shadows the name. Qualified references (A.B) are not covered yet. There are no TS2749 false positives in either full corpus.</summary>
  </entry>
  <entry>
    <title>JSX factory namespace in scope (TS2874) and factory option validation (TS5067/TS5059)</title>
    <id>https://ts-rs.bext.dev/progress#wave-27</id>
    <link href="https://ts-rs.bext.dev/progress#wave-27"/>
    <updated>2026-09-27T00:00:27Z</updated>
    <summary>TS2874: under jsx: react, each opening or self-closing tag needs the factory namespace as a value in scope, as in tsc's markJsxAliasReferenced. The namespace comes from a file @jsx pragma, else a valid jsxFactory, else reactNamespace as written, else React. It is resolved directly rather than through the identifier path, because that path deliberately tolerates common browser and React globals. Otherwise TS2874 is reported at the tag name, or TS2552 when a spelling suggestion exists. The check is skipped for files that reference libraries by /// &lt;reference&gt;, contain declare global, or opt into the automatic runtime by pragma. TS5067 / TS5059: invalid jsxFactory and reactNamespace values are reported. The raw option values are now kept, because an invalid jsxFactory was dropped at parse time.</summary>
  </entry>
  <entry>
    <title>import assignments under ES module kinds (TS1202)</title>
    <id>https://ts-rs.bext.dev/progress#wave-26</id>
    <link href="https://ts-rs.bext.dev/progress#wave-26"/>
    <updated>2026-09-27T00:00:26Z</updated>
    <summary>With module set to es2015, es2020, es2022 or esnext, a non-type-only, non-ambient import x = require(...) is now TS1202 on the whole statement, as in tsc's checkImportEqualsDeclaration, whatever the file extension. It is a grammar error, so it is skipped in files with syntax errors. There are no TS1202 false positives in either full corpus.</summary>
  </entry>
  <entry>
    <title>alias root hidden by a local declaration (TS2437)</title>
    <id>https://ts-rs.bext.dev/progress#wave-25</id>
    <link href="https://ts-rs.bext.dev/progress#wave-25"/>
    <updated>2026-09-27T00:00:25Z</updated>
    <summary>In a namespace block, import X = A.b whose target has a value meaning is now TS2437 at A when A resolves, for value or namespace meaning, to a local non-namespace declaration of that block (var, function or class). This follows tsc's checkImportEqualsDeclaration. There are no TS2437 false positives in either full corpus.</summary>
  </entry>
  <entry>
    <title>recursive interface bases (TS2310) and type-only namespaces as values (TS2708)</title>
    <id>https://ts-rs.bext.dev/progress#wave-24</id>
    <link href="https://ts-rs.bext.dev/progress#wave-24"/>
    <updated>2026-09-27T00:00:24Z</updated>
    <summary>TS2310: each interface whose extends graph (from interface_info) leads back to itself is reported at its name, printed with its type parameters (I1&lt;T&gt;). Class cycles (TS2506) are not included. TS2708: a value-position identifier that resolves at root scope to one of the file's namespaces with no value meaning is now TS2708, with an error type so member access adds nothing. Such a namespace has every block uninstantiated and no same-named var, function, class, enum, alias or import. Namespaces holding only const enums or import aliases count as values, as in tsc's ConstEnumOnly state. The check skips extends M.I (tsc's cannot-extend-an-interface case) and export default M (an alias of all meanings). It applies only in module files or single-file programs, since script namespaces merge across files.</summary>
  </entry>
  <entry>
    <title>built-in global redeclarations (TS2397) and TDZ gaps (TS2448)</title>
    <id>https://ts-rs.bext.dev/progress#wave-23</id>
    <link href="https://ts-rs.bext.dev/progress#wave-23"/>
    <updated>2026-09-27T00:00:23Z</updated>
    <summary>TS2397: in a script file, any top-level declaration named globalThis is reported at its name. So is a variable, function or namespace (not a type) named undefined. TS2448, three changes: A let/const loop binding of for...in/of is now ready only after the iterated expression, so for (let v of v) is an error. A destructured name is initialized only after its own default, so let [x2 = x2] = [] is an error, while [p, q = p] is still fine. Under outFile, a script's top-level (non-deferred) use of a block-scoped binding declared in a later script file is reported, with a related location in that file. The harness supplies program order. JS declaration files are not modeled yet (jsFileCompilationLetDeclarationOrder2). An ambient declare const no longer has a temporal dead zone.</summary>
  </entry>
  <entry>
    <title>merge conflict markers (TS1185) and value-less shorthands (TS18004)</title>
    <id>https://ts-rs.bext.dev/progress#wave-22</id>
    <link href="https://ts-rs.bext.dev/progress#wave-22"/>
    <updated>2026-09-27T00:00:22Z</updated>
    <summary>TS1185: the scanner already skipped merge conflict markers as trivia but reported nothing. It now records each marker's start on its cold path. parse reports &quot;Merge conflict marker encountered.&quot; at the seven marker characters. This code does not count as a syntax error, so semantic checking continues, as in tsc. TS18004: a shorthand property ({ b }, or { b = 1 } in a destructuring target) whose name resolves to nothing is resolved like a bare identifier. tsc's TS2304/TS2552 for that name is reported as TS18004. Guards cover the shapes where tsc reports something else: reserved words and recovery shorthands that tsc parses as name: &lt;missing&gt;, { a = 1 } outside a destructuring target (TS1312 only), and type-only imports (TS1361). There are no TS18004 or TS1185 false positives in either full corpus.</summary>
  </entry>
  <entry>
    <title>import-equals aliases that collide with a var (TS2440)</title>
    <id>https://ts-rs.bext.dev/progress#wave-21</id>
    <link href="https://ts-rs.bext.dev/progress#wave-21"/>
    <updated>2026-09-27T00:00:21Z</updated>
    <summary>The binder binds import x = &lt;entity&gt; as a function-scoped variable, so it merged silently with var x. The new import_alias_conflicts.rs follows tsc's checkAliasSymbol. Such a pair is TS2440, reported at the import statement, when the alias target has a value meaning: a var, function, class or regular enum, an instantiated namespace, or any require. Targets are resolved through the file's own namespaces. Exported aliases are also compared with exported vars in merged blocks of the same namespace. Unresolvable targets are skipped. The TS2440 false positives that remain in the full-corpus report come from existing binder rules (ES imports against classes and namespaces), not from this pass.</summary>
  </entry>
  <entry>
    <title>directive options located in the test's tsconfig</title>
    <id>https://ts-rs.bext.dev/progress#wave-20</id>
    <link href="https://ts-rs.bext.dev/progress#wave-20"/>
    <updated>2026-09-27T00:00:20Z</updated>
    <summary>When a test has a tsconfig.json, a deprecated option set only by a // @ directive is now reported at the tsconfig's &quot;compilerOptions&quot; key, as tsc's harness does. Previously it was reported as a global error. This change is harness-only.</summary>
  </entry>
  <entry>
    <title>unused renamings in bodyless signatures (TS2842)</title>
    <id>https://ts-rs.bext.dev/progress#wave-19</id>
    <link href="https://ts-rs.bext.dev/progress#wave-19"/>
    <updated>2026-09-27T00:00:19Z</updated>
    <summary>{ p: name } in a parameter of a signature with no body is now TS2842 when name is unused. This covers function and constructor types, call, construct and method signatures, overloads, and declare functions. A typeof name or name is T in the signature counts as a use. An unannotated parameter also gets tsc's related TS2843, placed at the end of the parameter.</summary>
  </entry>
  <entry>
    <title>namespace used as a type (TS2709)</title>
    <id>https://ts-rs.bext.dev/progress#wave-18</id>
    <link href="https://ts-rs.bext.dev/progress#wave-18"/>
    <updated>2026-09-27T00:00:18Z</updated>
    <summary>An identifier type reference that names one of the file's namespaces is now TS2709 when that name has no type meaning. A class, interface, alias, enum, type parameter, import or global type of the same name counts as a type meaning, as does a type declaration in an enclosing block or function scope. Namespaces reached through cross-file import aliases are not handled yet (noCrashOnImportShadowing, staticInstanceResolution5, moduleInTypePosition1). A reference recovered from extends Foo?.Bar is skipped, because tsc reports only TS2499 there. There are no TS2709 false positives in either full corpus.</summary>
  </entry>
  <entry>
    <title>emit-helper diagnostics under importHelpers (TS2354/TS2343)</title>
    <id>https://ts-rs.bext.dev/progress#wave-17</id>
    <link href="https://ts-rs.bext.dev/progress#wave-17"/>
    <updated>2026-09-27T00:00:17Z</updated>
    <summary>The new external_helpers.rs ports tsc's checkExternalEmitHelpers. Syntax that lowers to a tslib helper records a request, using tsc's target and option gates, its helper bits and its error location. This covers class extends, object spread/rest, legacy and ES decorators (including __setFunctionName and __propKey), metadata, __param, async functions and generators, yield*, for await, down-levelled iteration, tagged templates, private-field get/set/in, using, and module interop (import *, { default }, export *).</summary>
  </entry>
  <entry>
    <title>super property access outside a method (TS2660)</title>
    <id>https://ts-rs.bext.dev/progress#wave-16</id>
    <link href="https://ts-rs.bext.dev/progress#wave-16"/>
    <updated>2026-09-27T00:00:16Z</updated>
    <summary>super.x must have a class member, or an object-literal method or accessor, as its nearest non-arrow container. This follows tsc's getSuperContainer. Function scopes now carry a marker saying whether super properties are legal there. Class members, property initializers, static blocks and object-literal methods allow them. Function declarations and expressions do not. Arrows carry no marker, so they defer to their container.</summary>
  </entry>
  <entry>
    <title>switch-case comparability (TS2678)</title>
    <id>https://ts-rs.bext.dev/progress#wave-15</id>
    <link href="https://ts-rs.bext.dev/progress#wave-15"/>
    <updated>2026-09-27T00:00:15Z</updated>
    <summary>case expressions are now related to the switch expression's type, as in tsc's checkSwitchStatement. The rule reuses the TS2367 no-overlap logic, which was moved into comparison_no_overlap. That logic is now decided per union member, so string and number | &quot;hello&quot; overlap through &quot;hello&quot;. A class constructor (typeof C) never overlaps a primitive or literal type. The check skips null/undefined/any discriminants and intersections, because our intersections are not reduced (string &amp; number is never in tsc).</summary>
  </entry>
  <entry>
    <title>unreachable-code ranges follow tsc</title>
    <id>https://ts-rs.bext.dev/progress#wave-14</id>
    <link href="https://ts-rs.bext.dev/progress#wave-14"/>
    <updated>2026-09-27T00:00:14Z</updated>
    <summary>TS7027 now follows tsc's checkSourceElementUnreachable:</summary>
  </entry>
  <entry>
    <title>strict-mode parameter names and missing super() calls</title>
    <id>https://ts-rs.bext.dev/progress#wave-13</id>
    <link href="https://ts-rs.bext.dev/progress#wave-13"/>
    <updated>2026-09-27T00:00:13Z</updated>
    <summary>TS1100 now covers parameters named eval or arguments in strict code, in every signature (declarations, expressions, arrows, and type-position signatures), matching tsc's bindParameter; ambient signatures are exempt. Class members keep TS1210; modules (TS1215) are not yet covered. TS2377: a bodied constructor of a derived class must contain a super(...) call directly in its body; calls inside nested functions or arrows do not count (tsc's findFirstSuperCall). A heritage expression that is not a plain name is skipped, since it could be null.</summary>
  </entry>
  <entry>
    <title>overload implementation notes and single-arity candidates</title>
    <id>https://ts-rs.bext.dev/progress#wave-12</id>
    <link href="https://ts-rs.bext.dev/progress#wave-12"/>
    <updated>2026-09-27T00:00:12Z</updated>
    <summary>Overload sets now remember their bodied implementation (top-level functions and class methods, keyed by the callable signatures). When every overload rejects a call that the implementation would accept, the error carries tsc's TS2793 note at the implementation's name. When exactly one overload has a compatible argument count, the call reports that candidate's TS2345, as tsc does, instead of TS2769.</summary>
  </entry>
  <entry>
    <title>declaration notes for anonymous types and unconstrained type parameters</title>
    <id>https://ts-rs.bext.dev/progress#wave-11</id>
    <link href="https://ts-rs.bext.dev/progress#wave-11"/>
    <updated>2026-09-27T00:00:11Z</updated>
    <summary>Starting from b72e8c656, two related-information notes that tsc attaches to relation errors are now produced:</summary>
  </entry>
  <entry>
    <title>constructor diagnostic spans without rescanning</title>
    <id>https://ts-rs.bext.dev/progress#wave-10</id>
    <link href="https://ts-rs.bext.dev/progress#wave-10"/>
    <updated>2026-09-26T00:00:10Z</updated>
    <summary>Starting from cb92e8bc0, constructors retain the parser's keyword span in the AST. Overload compatibility uses that span instead of allocating a token stream for the entire constructor body. Missing-implementation diagnostics use the same endpoint. Both diagnostics include accessibility modifiers and intervening comments through the constructor keyword, matching TypeScript 6.0.3. A regression tests all three accessibility modifiers, unmodified constructors, Unicode comments, and the implementation's related diagnostic. The earlier protected constructor assertion is corrected to the upstream span.</summary>
  </entry>
  <entry>
    <title>public constructor overloads</title>
    <id>https://ts-rs.bext.dev/progress#wave-9</id>
    <link href="https://ts-rs.bext.dev/progress#wave-9"/>
    <updated>2026-09-08T00:00:09Z</updated>
    <summary>Class constructor relations, construction expressions, and super(...) calls now use public overload declarations, excluding the implementation signature. Ambient overload declarations remain separate signatures. Inherited signatures substitute each base's type arguments and dependent defaults while retaining the derived class as the constructed result. Parameter initializers infer their types and retain required positions before later required parameters.</summary>
  </entry>
  <entry>
    <title>instance member compatibility</title>
    <id>https://ts-rs.bext.dev/progress#wave-8</id>
    <link href="https://ts-rs.bext.dev/progress#wave-8"/>
    <updated>2026-09-08T00:00:08Z</updated>
    <summary>Instance inheritance and implementation checks now share the signature relation used for static members. They check overload sets, required parameters, generic constraints, instantiated base arguments, and method versus function-property variance. Inherited method metadata survives intermediate classes; a property redeclaration replaces that metadata. Alias intersections and optional interface members participate in implementation checks.</summary>
  </entry>
  <entry>
    <title>circular module aliases</title>
    <id>https://ts-rs.bext.dev/progress#wave-7</id>
    <link href="https://ts-rs.bext.dev/progress#wave-7"/>
    <updated>2026-09-08T00:00:07Z</updated>
    <summary>A shared program index now detects TS2303 cycles through import-equals, named and default imports, re-exports, ambient modules, and UMD namespace aliases. Dependency-first file order and declaration identity determine which alias receives the error. Export-assignment files have their own module scope in the index, preserving valid namespace-backed UMD declarations.</summary>
  </entry>
  <entry>
    <title>jump targets and duplicate labels</title>
    <id>https://ts-rs.bext.dev/progress#wave-6</id>
    <link href="https://ts-rs.bext.dev/progress#wave-6"/>
    <updated>2026-09-08T00:00:06Z</updated>
    <summary>break and continue now resolve their enclosing loop, switch, or label during the normal statement traversal. Invalid jumps report TS1104, TS1105, TS1107, TS1115, or TS1116 as appropriate. Chained labels preserve their iteration target, and duplicate enclosing labels report TS1114 with the original source spelling. Escaped label names use their decoded identity for matching.</summary>
  </entry>
  <entry>
    <title>static inheritance compatibility</title>
    <id>https://ts-rs.bext.dev/progress#wave-5</id>
    <link href="https://ts-rs.bext.dev/progress#wave-5"/>
    <updated>2026-09-08T00:00:05Z</updated>
    <summary>Class declarations and expressions now report TS2417 when their own static members conflict with the nearest inherited declaration. The check preserves source declaration order, private/protected visibility, optionality, getter read types, and callable overloads without their implementation signatures. Static generic methods retain their constraints and defaults. Method parameter bivariance applies separately to each overload pair; function-valued properties use the configured function variance rule. Heritage traversal detects cycles.</summary>
  </entry>
  <entry>
    <title>strictness defaults and option precedence</title>
    <id>https://ts-rs.bext.dev/progress#wave-4</id>
    <link href="https://ts-rs.bext.dev/progress#wave-4"/>
    <updated>2026-09-08T00:00:04Z</updated>
    <summary>Explicit noImplicitAny, strictNullChecks, strictFunctionTypes, and strictPropertyInitialization settings now override strict in either direction. Omitted settings inherit TypeScript 6's strict-by-default behavior. Property initialization and local definite-assignment checks use the effective null-check setting, including explicit opt-ins when strict is false.</summary>
  </entry>
  <entry>
    <title>implicit return types in signatures</title>
    <id>https://ts-rs.bext.dev/progress#wave-3</id>
    <link href="https://ts-rs.bext.dev/progress#wave-3"/>
    <updated>2026-09-08T00:00:03Z</updated>
    <summary>Add TS7013 for construct signatures and TS7020 for call signatures without return annotations under noImplicitAny. Named method signatures now use the same annotation traversals, covering inline and nested type literals as well as interfaces. TS7010 preserves quoted and computed name spelling and underlines the entire type-member signature. A single streaming token scan includes an explicit separator and intervening trivia without scanning the rest of the file. Constant-time deduplication prevents repeated annotation visits from reporting duplicate errors.</summary>
  </entry>
  <entry>
    <title>function completion diagnostics</title>
    <id>https://ts-rs.bext.dev/progress#wave-2</id>
    <link href="https://ts-rs.bext.dev/progress#wave-2"/>
    <updated>2026-09-08T00:00:02Z</updated>
    <summary>Add TS2355, TS2366, TS2534, and endpoint TS7030 checks for functions, arrows, methods, and getters. Shared flow analysis accounts for reachable returns, loops and labels, switch fallthrough, and try/catch/finally. Statement checking records explicit never-call and exhaustive-switch evidence while lexical bindings are available. Completion diagnostics use constant-time deduplication and skip body analysis when the return type permits implicit completion.</summary>
  </entry>
  <entry>
    <title>restore the workspace test gate</title>
    <id>https://ts-rs.bext.dev/progress#wave-1</id>
    <link href="https://ts-rs.bext.dev/progress#wave-1"/>
    <updated>2026-09-08T00:00:01Z</updated>
    <summary>The next wave restores test fixtures for added type metadata and updates stale expectations for literal types, diagnostic codes, declaration output, and enum properties. Checks against the installed TypeScript 6.0.3 compiler distinguish outdated assertions from implementation bugs.</summary>
  </entry>
  <entry>
    <title>missing binding-pattern argument notes</title>
    <id>https://ts-rs.bext.dev/progress#wave-0</id>
    <link href="https://ts-rs.bext.dev/progress#wave-0"/>
    <updated>2026-09-08T00:00:00Z</updated>
    <summary>Commit 04b90c6db adds TS6211 related information for omitted destructured parameters in functions, methods, and constructors. Three regression tests cover named parameters, object/array patterns, inherited constructors, supplied arguments, and defaults.</summary>
  </entry>
</feed>
