7.0 regression: inherited members are sorted by position, so an empty subinterface changes assignability
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- typescript
- Lĩnh vực
- compilers
Hướng nghiên cứu
Start by reviewing getNamedMembers in 7.0.2 or createMemberLayout on main, then compare how inherited members are ordered in the reproduction's deep.ts. Run tsc --noEmit --pretty false deep.ts and check whether wideC produces the same assignability error as wideB; an open linked pull request indicates work is already underway.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
🔎 Search Terms
inherited members order, member order, property order, interface extends, empty subinterface, variance, unmeasurable, getNamedMembers, createMemberLayout, missing TS2322, 7.0 regression
🕗 Version & Regression Information
- This changed between versions 6.0.3 and 7.0.2
- Still present in 7.1.0-dev.20261030.1.
- microsoft/typescript-go#1987 (first in
@typescript/native-preview7.0.0-dev.20251031.1) fixed this for one level of inheritance (Bbelow), but not for two (C).
⏯ Playground Link
No response
(Reproduction repo can be found here - it doesn't seem like Playground runs an applicable version for this issue).
💻 Code
export const empty: C<string> = {};
declare const narrowB: B<{ a: string }>;
export const wideB: B<{ a: string; b?: number }> = narrowB;
declare const narrowC: C<{ a: string }>;
export const wideC: C<{ a: string; b?: number }> = narrowC;
interface A<T> {
inherited: () => T;
}
interface B<T> extends A<T> {
own: (x: T) => Required<T>;
}
interface C<T> extends B<T> {}
Run with tsc --noEmit --pretty false deep.ts and no tsconfig, since strict is the default. empty is only there for its message, which lists C's members in the order the checker compares them.
🙁 Actual behavior
With 7.0.2 and 7.1.0-dev.20261030.1, wideC compiles, though C adds nothing to B and the same assignment to B is an error:
deep.ts(1,14): error TS2739: Type '{}' is missing the following properties from type 'C<string>': inherited, own
deep.ts(3,14): error TS2322: Type 'B<{ a: string; }>' is not assignable to type 'B<{ a: string; b?: number | undefined; }>'.
The types returned by 'own(...)' are incompatible between these types.
Property 'b' is missing in type 'Required<{ a: string; }>' but required in type 'Required<{ a: string; b?: number | undefined; }>'.
🙂 Expected behavior
wideC is an error, like wideB, as in 6.0.3:
deep.ts(1,14): error TS2739: Type '{}' is missing the following properties from type 'C<string>': own, inherited
deep.ts(3,14): error TS2322: Type 'B<{ a: string; }>' is not assignable to type 'B<{ a: string; b?: number | undefined; }>'.
The types returned by 'own(...)' are incompatible between these types.
Property 'b' is missing in type 'Required<{ a: string; }>' but required in type 'Required<{ a: string; b?: number | undefined; }>'.
deep.ts(5,14): error TS2322: Type 'C<{ a: string; }>' is not assignable to type 'C<{ a: string; b?: number | undefined; }>'.
The types returned by 'own(...)' are incompatible between these types.
Property 'b' is missing in type 'Required<{ a: string; }>' but required in type 'Required<{ a: string; b?: number | undefined; }>'.
Additional information about the issue
C has no members of its own, so all of its properties are inherited, and they are sorted by declaration position (getNamedMembers in 7.0.2, createMemberLayout on main): inherited, declared in A, comes before own, declared in B. 6.0 takes C's inherited members from B in B's order, which puts B's own members first: own, inherited.
The order changes assignability through variance measurement, which relates C<Sub> to C<Super> and back member by member, stopping at the first member that fails. Required<T> in own marks T unmeasurable (the -?), but only when relating C<Super> to C<Sub>, and that direction fails at inherited first when inherited comes first. T is then measured plain invariant: --generateTrace shows B as [in out (unmeasurable)] and C as [in out]. Invariant, wideC passes because { a: string } and { a: string; b?: number } are each assignable to the other, while wideB gets the structural check that finds own's return types incompatible.
A fix: order inherited members by base type, and within a base type in that base's order, as 6.0 does.
Related, and already fixed on main: in 7.0.2 the order could also depend on other files. An inherited member counted as the interface's own when its text range fell inside the range of one of the interface's declarations in another file, such as a module augmentation, because isDeclarationContainedBy doesn't compare files, so a longer comment in an augmentation could make an assignment compile. #64915 replaced that check for classes and interfaces (first in 7.1.0-dev.20261024.1). I can share a repro if it matters for 7.0.
Found because a library relies on a -? member like own for exact assignments between instantiations of its schema type, and interfaces extending that type lost them on 7.0.
- Ngôn ngữ chính
- Go
- Star
- 112k
- Fork
- 16k
- Merge trung bình
- 3 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 136
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của microsoft/TypeScript
-
API: `tsc.exe` opens a visible console window on Windows when the parent process has no consoleĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
microsoft/TypeScript#65083 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
TS7 LSP: documentHighlight returns nothing when the file path contains '@'Có thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mởBug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
microsoft/TypeScript#64758 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Language server (tsc --lsp) exits with code 1 after `shutdown` and `exit`Có thể đã có người làm @rajnish-verma-22172 đã nhận 11 ngày trước. Đang mởBug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
microsoft/TypeScript#64742 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Class names `eval` and `arguments` are not reported as invalid strict mode bindingsCó thể đã có người làm @dmety đã nhận 24 ngày trước. Đang mởBug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
microsoft/TypeScript#64661 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Non-enum CLI options with multiple values separated by comma and space aren't whitespace trimmedCó thể đã có người làm @RyanCavanaugh đã nhận 25 ngày trước. Đang mởBug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
microsoft/TypeScript#64618 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của microsoft/TypeScript
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement tariffs
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
evcc-io/evcc#35698 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày