Список согласованных модулей: (Consistent units list)

Состоит из согласованых модулей. Порядок сортировки юнитов в списке зависит от типа запроса. Каждый модуль в этом списке уникальный, дублицирование модулей неразрешается (Is_Equal или Is_Identical).
{ Сортировка списка для отношений:
Ancestors - от предка (заказаного модуля) к его родителю вплорть до Standard RM 10.1.1 (1) Если параметрами такого типа запроса является список модулей, то цепочка предок-родитель будет полной только для первого модуля, далее будет следовать заказанный модуль 2 и его родители, за исключением тех родителей, которые уже вошли ранее как радители 1 модуля и т.д. для всех последующих запрошенных модулей}

Список несогласованных модулей: (Inconsistent units list)

Второй список состоит из пар.

Каждая пара описует отношение зависимости семантической несогласованности. Правый модуль в паре зависит от левого. Все правые модули в парах - несогласованные и не попадают в список согласованных модулей (первый список). Левый {крайний левый, или 1 модуль списка}* модуль может быть согласованным либо нет. Если он согласованный он также находиться в списоке согласованных модулей, иначе он часть транзитивной несогласованной зависимости (т.е. есть еще пара, где этот модуль стоит справа)

{* аргументация - 1 модуль уже валидный, 2 зависит от него но еще невалидный, поэтому мы можем сразу проверять 2 модуль на соответствие 1, т.е. ненадо для 2 модуля искать причину невалидности.}

Пары упорядоченны так, что нет семантической зависимости "вперед" между несогласованными модулями. Все вспомогательные модули для несогласованного модуля находятся в списке слева.

Например, возьмем 4-ре модуля, А включает (with) B, B включает C и C включает D. Если D изменился {в данном примере он уже валидный, с него список и начинается}, список несогласовонности состоит из 6 модулей, трех пар

  DC  CB  BA

Список означает, что модули C, B и A несогласованные (они справа в парах) Также видны семантические зависимости, такие как "модуль B зависит от C". Модули C, B и A указаны в том порядке, в котором они могут быть отправленны на компиляци.

Если модуль стал несоглассован из-за редактирования его текста (другой причиной может некоторое действие пользователя или реализации), то Nil_Compilation_Unit используется чтобы показать причину несоглосованности (например (Nil A Nil B) [здесь список из четырех модулей] - список из двух несогласованных модулей для каждого из которых нельзя использовать никакой третий модудь как причину несогласованности)

{По русски: Nil_Compilation_Unit перед 1 елементом обозначает что у модуля поменялись сорцы, поэтому его надо отправлять на перекомпиляцию, а дальнейшая цепочка будет ПОСЛЕ этого невалидной, Nill_D DC CB BA; далее вытекает ситуация когда D будет перекомпилирован, но все модули от него зависяхие будут с ним несогласованы, тогда список будет как в примере выше.
Остается вопрос что делать если исходники B тоже менялись, надо ли список составлять как Nill_D DC CB Nill_B BA}

Реализации разрешается:

Использовать Nil_Compilation_Unit первым в каждой паре, если реализация не может определить какой из вспомогательных модулей привел к несогласованности.

Тут мне не понятно отчего возник этот пример:

Для примера выше возвращаемый список будет:

   DC DB DA CB CA BA

Этот список означает следующие зависимости

D включен в C, С включен в B, B включен в A => DC DB DA
               С включен в B, B включен в A => CB CA
                              B включен в A => BA

Список недостающих модулей: (Missing units list)

Третий список сотоит из пар модулей. Каждая пара состоит из модуля в левой части, который зависит от недостающего модуля помещенного в правую чать пары. Для такого недостающего модуля известно его название и Unit_Kind которго = A_Nonexistent_Declaration или A_Nonexistent_Body.

Для примера:

Лист бутед состоять из модулей: AB AC

      If Unit_Kind(B) = A_Nonexistent_Declaration and
        Unit_Kind(C) = A_Nonexistent_Body then

Из этот следует что а зависит от декларации модуля В для которого несуществует декларации, а так же А зависит от тела С (зависимость от тела может быть разной в зависимости от типа модуля А, тело модуля С может быть телом от которого зависит А или телом подмодуля А) для которого нет тела. Модуль помечается как пропавший только если правила посткомпиляции требуют его наличия Reference Manual 10.2.

Список циклической зависимости (Circular dependence list)

В этом списке отображаются циклические зависимости между пакетами. Опрядок следования модулей определяется типом запроса. В списке может быть отображено несколько наборов циклических зависимостей. В список не включаются недостающие модули. Список состоит из пар модулей, вторая честь которого зависит от первой. Цикличность определяется теа, что левая часть 1 пары появляется как правая часть последующей пары. (См. приемр ниже. Модуль А является левой частью пары 1 и правой пары 3, далее следует следующая циклическия зависимость модуля D).

Пример, спасок циклических зависимостей

AC CB BA DG GF FE ED

По этому списку можно определить две циклических зависимости {A, B, C} и {D, E, F, G} О каждой циклический зависимости сообщается только 1 раз, т.е. для зависимости модуля C (C->B->A->C), из примера, строить цепочку ненужно.