scriptc

알려진 컴파일러 버그 (v0.3.0, issue #963). 제네릭 클래스 인스턴스의 어느 곳에서든 computed-key 쓰기(예: 리터럴이 아닌 키를 사용한 (obj as any)[key] = fn)가 발생하면, method-name census가 해당 클래스의 메서드를 prototypeMethodAccesses로 강등시킵니다. 이후 lowering된 코드는 dyn.hasKey 가드 없이 인스턴스별 동적 프로퍼티 bag을 읽고, classPrototypeData는 제네릭/제네릭 인스턴스 클래스에 대해 null을 반환하므로 프로토타입 fallback이 없습니다. 따라서 bag 읽기는 undefined를 반환하고 호출이 예외를 던집니다. 비제네릭 클래스는 prototype-data 헬퍼가 생성되므로 영향을 받지 않습니다.

컴파일러 수정이 적용될 때까지의 해결 방법:
1. 제네릭 클래스 인스턴스에서 동적 키 쓰기를 제거하세요 — 외부 메타데이터를 별도의 Map/사이드 테이블에 저장하거나 obj[expr] = value 대신 리터럴 프로퍼티 할당을 사용하세요.
2. 가능하다면 타입 매개변수를 제거하여(Ctx<T> 대신 구체적인 타입 사용) 클래스가 비제네릭 경로로 컴파일되도록 하세요. 이 경로에서는 prototype-data 헬퍼가 생성되어 메서드가 올바르게 해석됩니다.

논의 중인 컴파일러 측 수정 방향: bag 읽기에 fallback이 제공되도록 제네릭 인스턴스에 대한 프로토타입 데이터를 생성하거나, 읽기가 정적 메서드로 fallback되도록 제네릭 클래스의 메서드에 대해 dyn.hasKey 가드를 유지하는 방안입니다.

SC1090은 컴파일러가 수신자의 런타임 클래스를 정적으로 증명할 수 없음을 의미하며, 이는 제네릭 메서드가 정적으로 디스패치되기 때문에 필요합니다. 이는 객체가 any를 거쳐 인터페이스로 다시 캐스팅될 때 발생합니다 (예: const restored = erased as GenericIdentity; restored.id(42)). 이 패턴은 아직 지원되지 않습니다 (기능 요청 #905). 해결 방법: (1) 객체가 any로 지워지기 전에 원래 타입이 지정된 객체에서 제네릭 메서드를 직접 호출하세요 — 원래 객체를 통한 직접 호출은 지원됩니다. (2) 클래스 인스턴스의 경우, 클래스를 증명할 수 있도록 수신자를 new 표현식으로 초기화된 const에 바인딩하세요: const r: GenericIdentity = new C(...). 참고: any 또는 타입 소거된 저장소를 왕복해야 하는 객체 리터럴의 제네릭 화살표 함수 프로퍼티에 대한 해결 방법은 현재 없습니다.