Ну хорошо, для того, чтобы это работало надо иметь плагин sonar-pvs-studio-plugin, который Вы распространяете по коммерческой лицензии (это тут написано www.viva64.com/ru/m/0037). А если перейти к корневому комментарию, то об этом я Вам и сообщил)
Я тоже пользуюсь SonarLint, однако для CLion его нет, хотя при этом проект с c++ инспекциями есть, но пока у них даже в roadmap нет на CLion никаких планов. Также есть еще плагин для SonarQube под названием sonar-cxx, также бесплатный. Туда же можно подцепить coverity, cppcheck, facebook-infer и clang-tidy. Единственное неудобство доставляет PVS, который приходится запускать через скрипт и анализировать результаты отдельно)
1. Скажите, пожалуйста, если у вас есть возможность бесплатного использования анализатора, тогда почему плагин для SonarQube идет только для коммерческого использования в то время как большинство Open Source проектов как раз его (SonarQube) и используют? Сама платформа SonarQube также бесплатна для использования. Где-то что-то не сходится.
2. Я так понимаю, что плагины для Intellij Idea это тоже только коммерческая фишка? Вы о нем уже говорите в 3-й статье, а в общем репозитории его не найти. А как же CLion и Rider?
Мне иногда кажется, что лучшим решением для CLion, на текущий момент, было бы — немного притормозить с внедрением новой функциональности и в 1 релиз все силы кинуть на фикс существующих многочисленных багов в уже существующей функциональности. За последние 2 года я насоздавал в Вашем баг-трекере более 70 откровенных багов и проблем, приводящих к тому, что пользоваться той или иной функцией IDE затруднительно или невозможно. Ни один баг так и не был поправлен. Видимо это связано с «есть более приоритетные задачи». Я разрабатываю несколько кросс-платформеных приложений и у меня возникало непонимание — почему в одной и той-же версии IDE и одном и том же проекте — баги (в области работы с исходным кодом) разные. Начал изучать вопрос и понял. У Вас существует проблема — часть фиксов, которая идет с обновлением просто не применяется к старой версии. На всех 3 моих IDE CLion на разных ОС с и с разной начальной версией установки разный набор «недоисправленных» багов. Жду момента когда смогу всецело пересесть с громоздкой и неповоротливой VS и пока так и не получается…
Я с Вами соглашусь, и даже скажу, что статически анализом абсолютно невозможно решить целые классы задач в области параллельного кода, однако, мой опыт работы со множеством параллельных математических, научных библиотек и опыт работы с иными библиотеками, где есть какой-то параллельный код показывает, что программисты, зачастую, делают абсолютно простейшие ошибки при написании такого кода, можно даже глубоко не лезть.
Для статического анализа подойдут такие простейшие проверки:
1. Внутри потока все исключения, которые могут произойти должны перехватываться.
2. Явный вызов join() или detach() после порождения потока далее по контексту (STL only).
3. Передача значения по ссылке std::cref() если оно не изменяется в потоке или далее по контексту выполнения.
4. Использование lock_guard() и unique_lock() c объектами синхронизации (не везде).
5. Использование scoped_lock() если надо заблокировать несколько объектов синхронизации.
И т.д.
Статический анализ свое место под солнцем может завоевать.
Умеет ли PVS-Studio, хоть в каком-то виде, анализировать контекст происходящего в коде?
1. Если ДА, то хотелось бы видеть в Вашем продукте ряд проверок, направленных на анализ многопоточного кода. Абстрактно размышляя, количество объектов и методов синхронизации конечное множество, при этом, довольно, малое. Поиск параллельных участков кода и данных, с которыми имеют дело этот код — задача, достаточно, тривиальная. И при этом, количество диагностик, которые можно было бы написать в этой области достаточно большое (учитывая именно статический анализ кода, естественно, что покрывается не все и поэтому без valgrind и sanitaizer-ов не обойтись). Так же Ваш любимый CWE-362: Race Condition.
2. Так же хотелось бы видеть интеграцию со сборочными решениями уровня Enterprise (как единой точки входа для анализа) и иными IDE (в качестве полноценных плагинов) где это поддерживается, например, CLion/IntelliJ IDEA(в будущем), чтобы не править CMake файлы сборки.
Планируете ли Вы в будущем выпустить плагины для таких IDE, как CLion и Rider для более удобной и продуктивной работы с PVS-Studio в Linux системах? Спасибо.
2. Я так понимаю, что плагины для Intellij Idea это тоже только коммерческая фишка? Вы о нем уже говорите в 3-й статье, а в общем репозитории его не найти. А как же CLion и Rider?
Для статического анализа подойдут такие простейшие проверки:
1. Внутри потока все исключения, которые могут произойти должны перехватываться.
2. Явный вызов join() или detach() после порождения потока далее по контексту (STL only).
3. Передача значения по ссылке std::cref() если оно не изменяется в потоке или далее по контексту выполнения.
4. Использование lock_guard() и unique_lock() c объектами синхронизации (не везде).
5. Использование scoped_lock() если надо заблокировать несколько объектов синхронизации.
И т.д.
Статический анализ свое место под солнцем может завоевать.
1. Если ДА, то хотелось бы видеть в Вашем продукте ряд проверок, направленных на анализ многопоточного кода. Абстрактно размышляя, количество объектов и методов синхронизации конечное множество, при этом, довольно, малое. Поиск параллельных участков кода и данных, с которыми имеют дело этот код — задача, достаточно, тривиальная. И при этом, количество диагностик, которые можно было бы написать в этой области достаточно большое (учитывая именно статический анализ кода, естественно, что покрывается не все и поэтому без valgrind и sanitaizer-ов не обойтись). Так же Ваш любимый CWE-362: Race Condition.
2. Так же хотелось бы видеть интеграцию со сборочными решениями уровня Enterprise (как единой точки входа для анализа) и иными IDE (в качестве полноценных плагинов) где это поддерживается, например, CLion/IntelliJ IDEA(в будущем), чтобы не править CMake файлы сборки.
Спасибо.