Плагин это всё-таки полноценная интеграция - в текущей версии с просмотрщиком как минимум есть возможность по подавлению ложных срабатываний, фильтрации по ключевым словам и файлам и т.п. , не всё из этого есть в стандартных окошках просмотра ошибок компиляции - если вы сейчас говорите про них.
Но главное преимущество плагина это, конечно, то, что мы планируем в последующих версиях завести в него "бесшовный" запуск анализа непосредственно из IDE, без необходимости править файлы сборочной системы. Вариант с CMake модулем конечно также останется, например, для серверного запуска, однако кажется, что прямой запуск из IDE можно сделать удобнее.
В нашей документации есть соответствующий раздел. Проcто стоит учесть, что описанные в нём сценарии уже несколько устарели (сейчас мы, в целом, не рекомендуем нашим пользователям лезть на такой низкий уровень настройки анализатора), и там могут быть описаны не все возможные параметры настройки. Но общую идею из этого документа понять можно, мне кажется. Если что, коллега @Minatychможет дополнит про какие-то более специфичные настройки, которые вам могут быть интересны.
PVS-Studio поддерживает языки C, C++, Java и C#. Соответственно, из перечисленных пунктов, для поддерживаемых нами языков, часть из данных требований мы поддерживаем (например, классификации по OWASP и CWE), часть не поддерживаем (например, HIPAA и анализ бинарных файлов). У нас есть поиск потенциальных уязвимостей, но нет поиска НДВ.
Т.е. именно по критичным для вас требованиям у нас сейчас есть не все возможности и не все языки.
Если вам интересно подробнее обсудить соответсвие данным специфичным требованиям по тем языкам, что мы поддерживаем, я думаю, нам лучше было бы перейти в формат более личной беседы - если бы вы отправили нам этот список в поддержку, мы бы ответили подробнее по каждому конкретному пункту.
По поводу сравнения с другими решениями - мы пробовали такой формат, уже достаточно давно, лет 6-7 назад, и пришли к выводу, что это, скорее, достаточно неблагодарное занятие, если мы занимаемся этим сами. К сожалению, у читателя всегда остаётся ощущение предвзятости. Сравнение анализаторов вообще достаточно сложная задача, т.к. оно затрагивает очень много факторов, и, в большлинстве случаев, результатом получается некое пересечение множеств - каждый анализатор умеет что-то своё, что не умеет другой.
Поэтому сравнивать, как мне кажется, имеет смысл по какой-то конкретной характерристике, а не в общем. Если вас интересует что-то такое конкретное именно в плане сравнения с Solar appScreener - если вы её уточните, я попробую что-нибудь найти для вас.
Смотрите - именно типы ошибок, если мы говорим об анализе общего назначения (т.к. например диагностики по стандарту MISRA С точно никогда не пересекуться с другими языками), между данными 3-мя языками (C++, C#, Java) пересекаются достаточно сильно - речь идёт о десятках процентов таких общих ошибок. Это, однако, не означает, что в одном из анализаторов мы получаем "бесплатные" ошибки, если они уже есть в другом - по крайней мере, в случае с PVS-Studio, нам всё-равно приходится реализовывать такие общие диагностики в каждом анализаторе отдельно.
Конечно, мы переиспользуем уже имеющуюся экспертизу по такой диагностике, что сильно помогает, но это всё-таки не "бесплатно". Теоретически, такай подхват общих диагностик анализаторами для разных языков возможен (и мы знаем, что такие анализаторы есть) - обычно это делается на уровне некоего общего промежуточного представления, в котором работают сразу несколько анализаторов, однако в случае с PVS-Studio исторически сложилось так, что каждый анализатор уникален.
Безусловно у нас в командах много чего для внутренних нужд делается, не связанное со стат анализом, но коммерчески или даже просто публично пока только его предоставляем.
На самом деле, сам статический анализ - достаточно широкая область, помимо традиционного "поиска ошибок в коде". Это и всяческий рефакторинг и кодстайлы, это и защищённость (SAST) и безопасность (MISRA, AUTOSAR) кода, это и анализ состава ПО (SCA), где методики статического анализа также используются - статический анализ это инструмент, которым очень много задач можно решать во множестве областей, и мы последние годы многое из перечисленного выше стали затрагивать в той или иной мере.
Может быть снэпшоты и можно было бы получить, но и для получения дампа пришлось повозиться с бюрократией, так что вариант с генерацией нам на тот момент показался проще — если бы не получилось воспроизвести там, то возможно пошли бы дальше копать в сторону дампа.
Действительно, гонять проверку и заниматься оптимизацией на клиентском коде было бы проще всего, однако возникают проблемы юридического плана — мало кто отдаст всю свою кодовую базу в стороннюю компанию, а уж сколько документов придётся для этого оформлять.
На самом деле, у нас был пяток исходных файлов от клиента, которые он прислал нам по взаимному согласию. На их основе мы, с помощью специального алгоритма, сгенерировали десятки тысяч похожих фалов — по размеру, концентрации и степени вложенности конструкций ветвления кода, связанности кода через перекрёстные вызовы методов и т.п. Сам Roslyn, на основе которого работает анализатор, позволяет решать такие задачи достаточно удобно. И уже на этом синтетическом проекте мы воспроизвели описанные в статье проблемы.
Где-то в другом месте может быть и есть, но здесь это кажется лишним шумом.
Мне кажется, зачастую только автор кода может определить, является ли конкретное место ошибкой или нет, так что здесь я так категорически не стал бы судить.
Я согласен, что это интересное срабатывание для вас, и вы наверняка гордитесь таким межпроцедурным анализом, это всё понятно. Вопрос в том, есть ли от него польза пользователям.
Если же говорить про такой межпроцедурный анализ, то после того, как мы стали в прошлом году его расширять, например, у нашего C# анализатора стало больше фидбека от пользователей, больше интереса к нему и общения в поддержке. А несколько пользователей напрямую спрашивали именно о таких возможностях анализатора. Так что сейчас кажется, что мы сделали такой межпроцедурный анализ не зря.
кажется, что вместо всего этого надо просто выдать один варнинг внутри updateResult
Анализатор внутри этого метода знает конечно, что оно всегда false, и если переменную с чем-то сравнивали бы, например, он бы на это ругнулся — но просто на return какого-то значения у нас диагностики нет.
А вот если бы этот return, возвращающий всегда false, зависел бы от входного значения параметра метода, передаваемого в изначальной точке вызова OnPressed? Тогда внутри самого метода мы бы не знали, что оно вернёт с таким входом false, и оставшийся кусок вызывающего метода станет недостижимым. А межпроцедурный анализ из точки вызова нам позволит это просчитать.
Неочевидно, что стоит выдавать какие-то варнинги в точках вызова, это только шум.
Инкапсуляция, исполнение контрактов — можно найти тысячу причин, почему что-то не стоит делать. А можно просто уметь это делать и находить сотни подобных интересных срабатываний, как это делает PVS-Studio )
Да, безусловно, ложно-положительные срабатывания неизбежны при работе статического анализатора, однако такой огромный процент скорее свидетельствует о том, что анализатор нужно дополнительно настроить перед использованием — отключить какие-то диагностики, добавить исключения на определённые файлы, unit тесты и т.п.
Точно не скажу, если где-то экран текста заполнить восклицательными знаками, оно падало. А размер стека у потоков, которые проверяют код, нам в анализаторе уже приходилось увеличивать (относительно значения по-умолчанию), иначе на некоторых тестовых проектах Roslyn падал, при проверке сгенерированных файлов.
В конце этой недели у нас запланирован релиз с поддержкой VS2019\C# 8.0. Конкретно по поддержке nullable reference и всего специфичного для них синтаксиса — анализатор будет понимать, что это такое, и что оно значит, но на работу каких-то диагностик nullable reference никакого влияния оказывать пока не будет, по крайней мере в этом релизе.
Например, если вы где-то глубоко в своём коде в не-nullable переменную всё-таки запишите null (что сделать можно с помощью оператора '!', например), и затем без проверки будете эту переменную использовать, анализатор это увидит и ругнётся. Возможно в дальнейшем наше поведение с не-nullable refernce типами будет меняться, посмотрим на отзывы пользователей, будем расширять нашу тестовую базу по мере того, как новый синтаксис будет приниматься на вооружение разработчиками.
Потому что он не только находит но ещё и обновляет чтобы быстрее анализировалось, понятно что это для скорости. Но, если бы была настроечка включающая одну базу на sln/CmakeLists то было бы имхо попроще.
У нас можно добавлять suppress файл как на уровень sln (в случае Visual Studio проектов), так и при использовании прямой CMake интеграции (с нашим CMake модулем) Suppress файлы, однако, работают на уровне исходных файлов, поэтому если кусок кода переедет из одного файла в другой, то diff всё равно вылезет.
Также, если sln генерится CMake'ом, то добавлять в него suppress может быть неудобно — в таком случае можно в каждый ваш проект добавить общий suppress файл (т.е. все проекты будут ссылаться на один файл), а чтобы не модифицировать каждый проект по-отдельности, suppress файлы можно добавлять в проекты через общие MSBuild props'ы.
На самом деле, у нас есть внутренние инструменты для «сравнения отчётов», мы их используем, например, в регрессионных тестах. Тем не менее, для конечного пользователя они, скорее всего, окажутся неудобными. Ведь при сравнении результатов работы анализатора, между получением которых прошло какое-то время, нужно учитывать, что проверяемый код мог правиться, в проверяемые файлы добавлялся код, из-за которого старый проверяемый код мог «съехать» и т.п. Поэтому, сравнение двух отчётов «в лоб» обычно неэффективно.
Существует ряд способов учитывать такие изменения, и показывать именно новые срабатывания анализатора. Например, можно использовать предоставляемые PVS-Studio различные (в зависимости от сборочной системы и платформы) способы инкрементального анализа, анализирую, в т.ч. и на коммитах, только модифицированные файлы. Можно видеть новые ошибки, которых не было в предыдущих отчётах, использую механизм подавления срабатываний (мой коллега в комментарии выше давал ссылку на его описание). Наконец, quality-control системы наподобие SonarQube (для которого у нас есть плагин), обычно предоставляют схожую функциональность. В конечном счёте, всё зависит от конкретного сценария использования анализатора.
Мы также предоставляем утилиты для рассылки писем с результатами анализа, для преобразования результатов в различные форматы и т.п., так что вставить результат в code review отчёт также не должно быть трудно.
Для коммерческого использования нужно купить лицензию, для open source можно получить лицензию бесплатно.
Напомню, что PVS-Studio прекрасно работает и с IntelliJ IDEA :)
Плагин это всё-таки полноценная интеграция - в текущей версии с просмотрщиком как минимум есть возможность по подавлению ложных срабатываний, фильтрации по ключевым словам и файлам и т.п. , не всё из этого есть в стандартных окошках просмотра ошибок компиляции - если вы сейчас говорите про них.
Но главное преимущество плагина это, конечно, то, что мы планируем в последующих версиях завести в него "бесшовный" запуск анализа непосредственно из IDE, без необходимости править файлы сборочной системы. Вариант с CMake модулем конечно также останется, например, для серверного запуска, однако кажется, что прямой запуск из IDE можно сделать удобнее.
В нашей документации есть соответствующий раздел. Проcто стоит учесть, что описанные в нём сценарии уже несколько устарели (сейчас мы, в целом, не рекомендуем нашим пользователям лезть на такой низкий уровень настройки анализатора), и там могут быть описаны не все возможные параметры настройки. Но общую идею из этого документа понять можно, мне кажется. Если что, коллега @Minatychможет дополнит про какие-то более специфичные настройки, которые вам могут быть интересны.
Спасибо, обязательно глянем.
PVS-Studio поддерживает языки C, C++, Java и C#. Соответственно, из перечисленных пунктов, для поддерживаемых нами языков, часть из данных требований мы поддерживаем (например, классификации по OWASP и CWE), часть не поддерживаем (например, HIPAA и анализ бинарных файлов). У нас есть поиск потенциальных уязвимостей, но нет поиска НДВ.
Т.е. именно по критичным для вас требованиям у нас сейчас есть не все возможности и не все языки.
Если вам интересно подробнее обсудить соответсвие данным специфичным требованиям по тем языкам, что мы поддерживаем, я думаю, нам лучше было бы перейти в формат более личной беседы - если бы вы отправили нам этот список в поддержку, мы бы ответили подробнее по каждому конкретному пункту.
Рад, что вам понравилось!
По поводу сравнения с другими решениями - мы пробовали такой формат, уже достаточно давно, лет 6-7 назад, и пришли к выводу, что это, скорее, достаточно неблагодарное занятие, если мы занимаемся этим сами. К сожалению, у читателя всегда остаётся ощущение предвзятости. Сравнение анализаторов вообще достаточно сложная задача, т.к. оно затрагивает очень много факторов, и, в большлинстве случаев, результатом получается некое пересечение множеств - каждый анализатор умеет что-то своё, что не умеет другой.
Поэтому сравнивать, как мне кажется, имеет смысл по какой-то конкретной характерристике, а не в общем. Если вас интересует что-то такое конкретное именно в плане сравнения с Solar appScreener - если вы её уточните, я попробую что-нибудь найти для вас.
Смотрите - именно типы ошибок, если мы говорим об анализе общего назначения (т.к. например диагностики по стандарту MISRA С точно никогда не пересекуться с другими языками), между данными 3-мя языками (C++, C#, Java) пересекаются достаточно сильно - речь идёт о десятках процентов таких общих ошибок. Это, однако, не означает, что в одном из анализаторов мы получаем "бесплатные" ошибки, если они уже есть в другом - по крайней мере, в случае с PVS-Studio, нам всё-равно приходится реализовывать такие общие диагностики в каждом анализаторе отдельно.
Конечно, мы переиспользуем уже имеющуюся экспертизу по такой диагностике, что сильно помогает, но это всё-таки не "бесплатно". Теоретически, такай подхват общих диагностик анализаторами для разных языков возможен (и мы знаем, что такие анализаторы есть) - обычно это делается на уровне некоего общего промежуточного представления, в котором работают сразу несколько анализаторов, однако в случае с PVS-Studio исторически сложилось так, что каждый анализатор уникален.
Безусловно у нас в командах много чего для внутренних нужд делается, не связанное со стат анализом, но коммерчески или даже просто публично пока только его предоставляем.
На самом деле, сам статический анализ - достаточно широкая область, помимо традиционного "поиска ошибок в коде". Это и всяческий рефакторинг и кодстайлы, это и защищённость (SAST) и безопасность (MISRA, AUTOSAR) кода, это и анализ состава ПО (SCA), где методики статического анализа также используются - статический анализ это инструмент, которым очень много задач можно решать во множестве областей, и мы последние годы многое из перечисленного выше стали затрагивать в той или иной мере.
Алгоритм наш собственный.
На самом деле, у нас был пяток исходных файлов от клиента, которые он прислал нам по взаимному согласию. На их основе мы, с помощью специального алгоритма, сгенерировали десятки тысяч похожих фалов — по размеру, концентрации и степени вложенности конструкций ветвления кода, связанности кода через перекрёстные вызовы методов и т.п. Сам Roslyn, на основе которого работает анализатор, позволяет решать такие задачи достаточно удобно. И уже на этом синтетическом проекте мы воспроизвели описанные в статье проблемы.
Мне кажется, зачастую только автор кода может определить, является ли конкретное место ошибкой или нет, так что здесь я так категорически не стал бы судить.
Если же говорить про такой межпроцедурный анализ, то после того, как мы стали в прошлом году его расширять, например, у нашего C# анализатора стало больше фидбека от пользователей, больше интереса к нему и общения в поддержке. А несколько пользователей напрямую спрашивали именно о таких возможностях анализатора. Так что сейчас кажется, что мы сделали такой межпроцедурный анализ не зря.
Анализатор внутри этого метода знает конечно, что оно всегда false, и если переменную с чем-то сравнивали бы, например, он бы на это ругнулся — но просто на return какого-то значения у нас диагностики нет.
А вот если бы этот return, возвращающий всегда false, зависел бы от входного значения параметра метода, передаваемого в изначальной точке вызова OnPressed? Тогда внутри самого метода мы бы не знали, что оно вернёт с таким входом false, и оставшийся кусок вызывающего метода станет недостижимым. А межпроцедурный анализ из точки вызова нам позволит это просчитать.
Инкапсуляция, исполнение контрактов — можно найти тысячу причин, почему что-то не стоит делать. А можно просто уметь это делать и находить сотни подобных интересных срабатываний, как это делает PVS-Studio )
Например, если вы где-то глубоко в своём коде в не-nullable переменную всё-таки запишите null (что сделать можно с помощью оператора '!', например), и затем без проверки будете эту переменную использовать, анализатор это увидит и ругнётся. Возможно в дальнейшем наше поведение с не-nullable refernce типами будет меняться, посмотрим на отзывы пользователей, будем расширять нашу тестовую базу по мере того, как новый синтаксис будет приниматься на вооружение разработчиками.
У нас можно добавлять suppress файл как на уровень sln (в случае Visual Studio проектов), так и при использовании прямой CMake интеграции (с нашим CMake модулем) Suppress файлы, однако, работают на уровне исходных файлов, поэтому если кусок кода переедет из одного файла в другой, то diff всё равно вылезет.
Также, если sln генерится CMake'ом, то добавлять в него suppress может быть неудобно — в таком случае можно в каждый ваш проект добавить общий suppress файл (т.е. все проекты будут ссылаться на один файл), а чтобы не модифицировать каждый проект по-отдельности, suppress файлы можно добавлять в проекты через общие MSBuild props'ы.
Существует ряд способов учитывать такие изменения, и показывать именно новые срабатывания анализатора. Например, можно использовать предоставляемые PVS-Studio различные (в зависимости от сборочной системы и платформы) способы инкрементального анализа, анализирую, в т.ч. и на коммитах, только модифицированные файлы. Можно видеть новые ошибки, которых не было в предыдущих отчётах, использую механизм подавления срабатываний (мой коллега в комментарии выше давал ссылку на его описание). Наконец, quality-control системы наподобие SonarQube (для которого у нас есть плагин), обычно предоставляют схожую функциональность. В конечном счёте, всё зависит от конкретного сценария использования анализатора.
Мы также предоставляем утилиты для рассылки писем с результатами анализа, для преобразования результатов в различные форматы и т.п., так что вставить результат в code review отчёт также не должно быть трудно.