Эта задача была помечена как содержащая конфиденциальную информацию, такую как уязвимости кода и утечки конфиденциальных данных, и доступна для просмотра только участниками репозитория
Исследуйте тест CTS в отношении разделов спецификации 5, 13 и 15.
Этот issue предназначен для отслеживания процесса анализа текущих тестов CTS. Задачи:
найти устаревшие тесты и те, которые не соответствуют современным спецификациям.
некоторые тесты могут требовать сложной функциональности.
некоторые тесты могут потребовать удаления из списков игнора CTS.
Раздел 5 тестовых случаев CTS:
Покрытие CTS (2024-12-09): 80.3% — цель: более 90%
Тесты с проблемами, которые нужно решить:
список игнора довольно информативен относительно раздела generics и предоставляет внутренние номера задач и списки связанных тестовых случаев (не может быть проверено со стороны нашего проекта). Кроме этих замечаний:
#IBB94B решил эти проблемы (уже объединён)Сомнительные особенности в тестах
Эти тесты используют входящие-выходящие ограничения на месте использования, на аннотациях: ограничение in/out применяется на месте использования, в то время как имеются инвариантные типовые аргументы на месте объявления. Эта особенность не упоминается в спецификациях lg. Если эта особенность не должна поддерживаться, эти тестовые случаи CTS можно переместить в недействительные тестовые случаи:
В этом файле есть ещё одна проблема, если мы вынесем in из аннотации: let a: A<X> = new A<X>(new Z()); let z: Y = a.methOut(), используется более общий тип (X), чем указанный (Y), в позиции out, что запрещено. - Эти тесты проваливаются потому что они используют этот синтаксис для создания экземпляров из спецификаций lg: new <typeArgument> Type():
25 тестов, индексированных от 0 до 24: 05. generics/02. generic_instantiations/01. type_arguments/type_arguments_of_parameterized_declarations/constr_args1_. sts
#IBB93A решил эту проблему (MERGED)
17 отрицательных тестов, индексированных от 0 до 16, ложно проваливаются из-за этой проблемы: 05. generics/02. generic_instantiations/01. type_arguments/type_arguments_of_parameterized_declarations/const_args1_neg_. sts
Примечание: в спецификациях грамматика создания экземпляра ('new' typeArguments? typeReference arguments?) запрещает создание типа new A<T>(params).В других тестах есть несколько примеров использования этого последнего синтаксиса. Рекомендовано уточнение спецификации. Недействительные/неправильные тестовые случаи
эти тесты находятся в списке игнорируемых, но содержат синтаксис типа T<U<V>>>, который раздел 5.1 не допускает. — должны быть обновлены или сделаны отрицательными.### Раздел 13:
покрытие CTS (2024-12-09): 89.1% — цель: 90+%
причина: переопределение константного значения; синтаксическая ошибка: в конструкции while должно быть одно выражение (которое может быть блочным выражением)
причина: 1) import_path_dir_2:31 — импорт требует ключевого слова as, 2) отсутствие объявления пакета в модуле module_a.sts. Устранение ошибок 1) и 2) позволяет тесту пройти успешно (#easy-correct)
описание устарело: син доступен из std/math по умолчанию
std — особый случай, возможно, не лучшая идея проверять явное и неявное введение на них - 3) вероятно, нужна ясность в спецификациях: импорт std имен со стороны пользователя приводит к тому, что син можно получить как син и как псевдоним, который он явно импортировал. Очень похоже на этот случай: import {sin as Sine, sin as SIN}, что должно привести к ошибке CTE. Должны ли мы допустить это?
Инструкция переэкспорта, старые названия также должны быть доступны -> Почему? Нужна подтверждение со стороны стандарта
В текущих спецификациях нет упоминания о функционале "Инструкция переэкспорта, старые названия также должны быть доступны" — он, скорее всего, уже удален
Решение: следует превратить его в отрицательный тест?### Раздел 15:
См. отдельный вопрос: #IBGUEL
