Help:Match: Difference between revisions

From Svacer Wiki
(Описание генерации инвариантов)
 
m (Пояснение и корректировки)
Line 2: Line 2:
В данной секции описывается алгоритм сопоставления предупреждений используемый Svacer для переноса разметки.
В данной секции описывается алгоритм сопоставления предупреждений используемый Svacer для переноса разметки.


Для каждого предупреждения в снимке (snapshot) вычисляется хэшкод из полей предупреждения и исходных файлов. В терминологии Svacer хэшкод именуется '''инвариантом'''. Инвариант используется для группировки предупреждений из разных снимков в рамках одной ветке. Каждое предупреждение в рамках '''одного снимка''' имеет уникальный инвариант.
Для каждого предупреждения в снимке (snapshot) вычисляется хэшкод из полей предупреждения и исходных файлов. В терминологии Svacer хэшкод именуется '''инвариантом'''. Инвариант используется для группировки предупреждений из разных снимков в рамках одной ветке. Каждое предупреждение в рамках '''одного снимка''' имеет '''уникальный''' инвариант.


Генерация инвариантов для снимка идет по следующему алгоритму:
Генерация инвариантов для снимка идет по следующему алгоритму:


Шаг 1 (формируем первый инвариант):
Шаг 1 (формируем первый, основной инвариант):


* пути всех файлов в снимке сортируются лексикографически
* пути всех файлов из предупреждений в снимке сортируются лексикографически
* для каждого пути вычисляется минимально возможный не конфликтующий путь, содержащий по крайней мере два сегмента (т.е включающий имя директории). Для Java файлов минимальный путь учитывает имя пакета, объявленного внутри файла (при наличии package declaration внутри).  Минимальный путь добавляется в хэш код инварианта
* для каждого пути вычисляется минимально возможный не конфликтующий суффикс пути (т.е конец пути содержащий имя файла), имеющий по крайней мере два сегмента (т.е включающий имя директории). Для Java файлов минимальный путь учитывает имя пакета, объявленного внутри файла (при наличии package declaration внутри).  Данный минимальный суффикс добавляется в хэш код инварианта
* В инвариант добавляются хэш коды следующих полей предупреждения: '''MTid ('''если поле пустое, то используятся поля '''Msg, warnClass), Function, Lang, Tool.'''
* В инвариант добавляются хэш коды следующих полей предупреждения: '''MTid ('''если поле пустое, то используются поля '''Msg, warnClass), Function, Lang, Tool.''' Поля '''Lang и Tool''' нормализуются, т.к в разные версии Svace могли иметь отличные именования полей.
* Формируется хэш-код строки кода из объекта сборки. При формировании хэшкода строки все whitespace-ы игнорируются. Если объект сборки отсутствует, то используется поле '''details'''  у предупреждения.
* Формируется хэш-код строки кода из объекта сборки. При формировании хэшкода строки все whitespace-ы игнорируются. Если объект сборки отсутствует, то используется поле '''details'''  у предупреждения.
* Если для нескольких предупреждений в снимке получился одинаковый инвариант, то конфликтующие предупреждения упорядочиваются по '''locID''' предупреждения (порядковый номер предупреждения в svres или sarif файле). В инвариант добавляется индекс предупреждения в данной конфликтной группе. Таким образом получаем уникальный инвариант для каждого предупреждения в снимке.
* Если для нескольких предупреждений в снимке получился одинаковый инвариант, то конфликтующие предупреждения упорядочиваются по '''locID''' предупреждения (порядковый номер предупреждения в svres или sarif файле, в данном случае полагаемся на детерминизм анализатора). В инвариант добавляется индекс предупреждения в данной конфликтной группе. Таким образом получаем уникальный инвариант для каждого предупреждения в снимке.


Шаг 2 (формируем второй инвариант):
Шаг 2 (формируем второй инвариант):
Line 18: Line 18:
* пути всех файлов в снимке сортируются лексикографически
* пути всех файлов в снимке сортируются лексикографически
* для каждого пути вычисляется минимально возможный не конфликтующий путь, содержащий по крайней мере два сегмента (т.е включающий имя директории). Для Java файлов минимальный путь учитывает имя пакета, объявленного внутри файла (при наличии package declaration внутри).  Минимальный путь добавляется в хэш код инварианта
* для каждого пути вычисляется минимально возможный не конфликтующий путь, содержащий по крайней мере два сегмента (т.е включающий имя директории). Для Java файлов минимальный путь учитывает имя пакета, объявленного внутри файла (при наличии package declaration внутри).  Минимальный путь добавляется в хэш код инварианта
* В инвариант добавляются хэш коды следующих полей предупреждения: '''MTid ('''если поле пустое, то используется поля '''Msg, warnClass), Function, Lang, Tool, Details''' (важное отличие от шага 1 - здесь используется поле Details у предупреждения)
* В инвариант добавляются хэш коды следующих полей предупреждения: '''MTid ('''если поле пустое, то используется поля '''Msg, warnClass), Function, Lang, Tool, Details''' (важное отличие от ''шага 1'' - здесь используется поле '''Details''' у предупреждения). Поля '''Lang и Tool''' нормализуются, т.к в разные версии Svace могли иметь отличные именования полей.
* Предупреждения в снимке делятся на группы по инварианту. В рамках одной группы предупреждения сортируются по '''Function,''' строке ('''line)''' и '''locID.''' Индекс предупреждения в группе добавляется к инварианту группы. Таким образом получаем уникальный инвариант для каждого предупреждения в снимке.
* Предупреждения в снимке делятся на группы по инварианту. В рамках одной группы предупреждения сортируются по '''Function,''' строке ('''line)''' и '''locID.''' Индекс предупреждения в группе добавляется к инварианту группы. Таким образом получаем уникальный инвариант для каждого предупреждения в снимке.


Шаг 3:
Шаг 3:


* Если предупреждения на ветке (branch) попали согласно ''инварианту 1'' в разные группы, а ''инварианту 2'' в одну, то для данных предупреждений будет использован ''инвариант 2'' , как более строгий.
* Если предупреждения на ветке (branch) попали согласно ''инварианту 1'' в разные группы, а ''инварианту 2'' в одну, то для данных предупреждений будет использован ''инвариант 2'' , как более строгий.  


Шаг 4:
Шаг 4:


* Проверяется, были ли ручные сопоставления предупреждений на ветке (branch) и инварианты корректируются исходя из таблицы ручных сопоставлений. При ручном сопоставлении предупреждениям назначается уникальный инвариант и запоминается информация об эквивалентности назначенного инварианта инвариантам полученным на шагах 1 и 2.
* Проверяется, были ли ручные сопоставления предупреждений на ветке (branch) и инварианты корректируются исходя из таблицы ручных сопоставлений. При ручном сопоставлении предупреждениям назначается уникальный инвариант и запоминается информация об эквивалентности назначенного инварианта инвариантам полученным на шагах 1 и 2.

Revision as of 09:06, 28 May 2024

Алгоритм сопоставления предупреждений

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

Для каждого предупреждения в снимке (snapshot) вычисляется хэшкод из полей предупреждения и исходных файлов. В терминологии Svacer хэшкод именуется инвариантом. Инвариант используется для группировки предупреждений из разных снимков в рамках одной ветке. Каждое предупреждение в рамках одного снимка имеет уникальный инвариант.

Генерация инвариантов для снимка идет по следующему алгоритму:

Шаг 1 (формируем первый, основной инвариант):

  • пути всех файлов из предупреждений в снимке сортируются лексикографически
  • для каждого пути вычисляется минимально возможный не конфликтующий суффикс пути (т.е конец пути содержащий имя файла), имеющий по крайней мере два сегмента (т.е включающий имя директории). Для Java файлов минимальный путь учитывает имя пакета, объявленного внутри файла (при наличии package declaration внутри). Данный минимальный суффикс добавляется в хэш код инварианта
  • В инвариант добавляются хэш коды следующих полей предупреждения: MTid (если поле пустое, то используются поля Msg, warnClass), Function, Lang, Tool. Поля Lang и Tool нормализуются, т.к в разные версии Svace могли иметь отличные именования полей.
  • Формируется хэш-код строки кода из объекта сборки. При формировании хэшкода строки все whitespace-ы игнорируются. Если объект сборки отсутствует, то используется поле details у предупреждения.
  • Если для нескольких предупреждений в снимке получился одинаковый инвариант, то конфликтующие предупреждения упорядочиваются по locID предупреждения (порядковый номер предупреждения в svres или sarif файле, в данном случае полагаемся на детерминизм анализатора). В инвариант добавляется индекс предупреждения в данной конфликтной группе. Таким образом получаем уникальный инвариант для каждого предупреждения в снимке.

Шаг 2 (формируем второй инвариант):

  • пути всех файлов в снимке сортируются лексикографически
  • для каждого пути вычисляется минимально возможный не конфликтующий путь, содержащий по крайней мере два сегмента (т.е включающий имя директории). Для Java файлов минимальный путь учитывает имя пакета, объявленного внутри файла (при наличии package declaration внутри). Минимальный путь добавляется в хэш код инварианта
  • В инвариант добавляются хэш коды следующих полей предупреждения: MTid (если поле пустое, то используется поля Msg, warnClass), Function, Lang, Tool, Details (важное отличие от шага 1 - здесь используется поле Details у предупреждения). Поля Lang и Tool нормализуются, т.к в разные версии Svace могли иметь отличные именования полей.
  • Предупреждения в снимке делятся на группы по инварианту. В рамках одной группы предупреждения сортируются по Function, строке (line) и locID. Индекс предупреждения в группе добавляется к инварианту группы. Таким образом получаем уникальный инвариант для каждого предупреждения в снимке.

Шаг 3:

  • Если предупреждения на ветке (branch) попали согласно инварианту 1 в разные группы, а инварианту 2 в одну, то для данных предупреждений будет использован инвариант 2 , как более строгий.

Шаг 4:

  • Проверяется, были ли ручные сопоставления предупреждений на ветке (branch) и инварианты корректируются исходя из таблицы ручных сопоставлений. При ручном сопоставлении предупреждениям назначается уникальный инвариант и запоминается информация об эквивалентности назначенного инварианта инвариантам полученным на шагах 1 и 2.