Работа с перемещением кода при сравнении отчетов статического анализа

Когда я запускаю инструмент статического анализа своей кодовой базы и получаю такие результаты:

...
arch/powerpc/kernel/time.c:102:5: warning: symbol 'decrementer_max' was not declared. Should it be static?
arch/powerpc/kernel/time.c:138:1: warning: symbol 'rtc_lock' was not declared. Should it be static?
arch/powerpc/kernel/time.c:361:37: warning: implicit cast to nocast type
...

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

Я мог бы просто diff просмотреть результаты статического анализа, но тогда, если кто-то вставит код в time.c в строке 50, предупреждения выше переместятся, и, поскольку номера строк изменились, diff сообщит мне, что они изменились.

Как я должен сравнивать их таким образом, чтобы иметь дело с перемещением кода в файле?

Поиск в Google «умных различий» и т. Д. Не дал результатов: в основном это умные различия кода, а не умные различия журналов. Инструменты анализа логов, такие как Greylog или Kibana, также кажутся плохо подходящими, предназначенными больше для другого и более общего анализа, чем для этой вполне конкретной задачи.

Есть ли что-то очевидное, что я упускаю? Или это проблема, когда я должен ожидать, что буду писать свои собственные инструменты?


person dja    schedule 17.12.2016    source источник
comment
Чтобы иметь умный diff, он должен понимать структуру сообщений, чтобы он мог интеллектуально сравнивать различные части структуры. Кто будет создавать такой инструмент для каждого отдельного инструмента статического анализа?   -  person Ira Baxter    schedule 17.12.2016
comment
Из справочного центра: Вопросы с просьбами порекомендовать или найти книгу, инструмент, программную библиотеку, учебное пособие или другой сторонний ресурс не относятся к теме Stack Overflow, поскольку они, как правило, привлекают самоуверенные ответы и спам.   -  person Ken White    schedule 17.12.2016
comment
Ира и Кен - я отредактировал вопрос, чтобы уточнить.   -  person dja    schedule 17.12.2016
comment
@dja: К сожалению для вас, мнение некоторых людей в SO состоит в том, что запрос инструмента дает вам мнение о том, что такое хороший инструмент, и они изобрели Закон, который говорит, что вы не можете этого сделать. Обратите внимание на закрытые флаги в вашем вопросе. (Мое мнение заключается в том, что если нет ровно 1 канонического ответа на вопрос, то ответ, который является полезным, также является мнением, поэтому я не согласен с этим законом). В то же время, если вы сможете правильно сформулировать свой вопрос, он может быть лучше воспринят в разделе «Рекомендации по программному обеспечению». softwarerecs.stackexchange.com/questions/ask   -  person Ira Baxter    schedule 17.12.2016
comment
Хорошо, я сейчас спрашиваю не о том, какие инструменты могут решить мою проблему, а о том, как решить мою проблему в целом.   -  person dja    schedule 17.12.2016
comment
Было бы несложно написать синтаксический анализатор, который определяет, какой компонент сообщения является комбинацией имени файла/номера строки по сравнению с сообщением журнала.   -  person ajd    schedule 20.12.2016


Ответы (2)


Вы можете поддерживать слияние кода и ошибок: вставляйте каждое сообщение об ошибке (без номера строки) после соответствующей строки кода. Затем, если кто-то вставит код в строку 50, (обновленное) слияние не будет иметь различий вокруг более поздних ошибок. Конечно, в строке 50 будет diff, который может вас заинтересовать или не заинтересовать. Если хотите, вы можете игнорировать фрагменты diff, которые не содержат сообщения об ошибке (для которых вам понадобятся какие-то отличительные маркер у каждого вставленного сообщения об ошибке).

person Michael Dyck    schedule 17.12.2016
comment
Хм, это интересная идея. Я попробую на этой неделе. - person dja; 18.12.2016

Я попробовал немного более простую настройку - как предложил @ajd, анализируя сообщения и выполняя сопоставление без учета номера строки.

Код находится по адресу https://github.com/daxtens/smart-sparse-diff

person dja    schedule 04.01.2017