Комментарии 7
Честно говоря, каждый раз как я пробую им пользоваться, то быстро натыкаюсь на невозможность что-то реализовать и наличие соответствующего issue. В результате - больно. Немного правил я написал, они работают, но эта вот боль всех прошлых попыток несколько отбивает желание продолжать писать правила пока не появится поддержка кучки вещей, которые пока только в планах и issues. При этом я понимаю, что так не у всех, ведь много правил уже написано, но, тем не менее, как-то стрёмно снова к нему делать подход.
Привет, спасибо за фидбек, а не подскажешь о каких именно issue идет речь?
Вот ещё одну старенькую нашёл: https://github.com/quasilyte/go-ruleguard/issues/78.
Ну и в целом-то проблема не в конкретных незакрытых issues, которые закрой и настанет щастье, а в том, что шаг вправо-влево от проторенной тропинки приводит к неподдерживаемому функционалу - причём зачастую не каким-то уникальным фичам, а вроде бы точно такому же как поддерживается, только немного отличающемуся… и, внезапно, ой.
Когда что-то не поддерживает gogrep - это ок, потому что можно и обычным grep-ом поискать если что. А когда не поддерживает ruleguard - это не ок, потому что обойти это как-то иначе обычно не удаётся… и в результате осенившая идея полезной проверки остаётся не реализованной или реализованной не полностью. Получаются эмоциональные качели между радостным "сейчас мы тут быстренько правило напишем и будет круто" и грустным "мда, оказывается, пока не напишем, или напишем но не совсем полноценное".
Не поймите меня неправильно - ruleguard обалденная тулза, я большой фанат, и нет, я не ною. :) Просто такой опыт использования как-бы намекает, что обычно это вызвано архитектурными проблемами. Например, нужно выкинуть gogrep и заменить чем-то другим. Я так понимаю, какие-то изменения в этом направлении уже идут, осталось дождаться результатов, и можно будет сделать следующий подход к этому инструменту.
Сейчас используется собственный форк gogrep, где теперь, например, поддерживается несколько новых форм частичного синтаксиса. Принципиально это не меняет того, что матчинг осуществляется по синтаксису, но немного развязывает руки для дальнейших расширений и интеграций. Ту проблему взаимодействия фильтров и вариадичных шаблонов я не решал потому что не нашёл эффективного и красивого решения.
В утилите perfguard используется гибридный подход. Почти все диагностики сделаны через правила ruleguard. Более глубокий анализ делается расширением, через обычный go/ast и прочие пакеты. go-critic, к слову, работает так же: простейшее через правила, остальное ручками. ruleguard не задумывался как единственный инструмент для статического анализа. Это легко встраиваемая библиотека для описания шаблонами того, что нудно писать руками.
Могу ещё добавить, что staticcheck внутри себя тоже имеет движок правил, похожий на ruleguard. Правда там вместо gogrep паттернов своеобразный S-expr синтаксис (как в лиспах). Этот движок, насколько мне известно, внутренний и никогда не продвигался как механизм расширения staticcheck. ruleguard - это более публичный продукт в этой же области. Ни в staticcheck, ни в go-critic, эти движки не могут предоставить 100% решения задач. Но они сильно упрощают добавление типовых паттернов и/или прототипирование диагностик.
Из совсем революционного: скоро в Where будет гораздо меньше ограничений благодаря смешиванию статически реализованных правил и того, что будет исполняться через интерпретатор quasigo. Правда там же будет релиз dsl v1, который внесёт обратно-несовместимые изменения, но даст некоторую гарантию стабильности в будущем (TODO по DSL уже долго накапливались).
Кажется, в такой ситуации может помочь вот такой метод m.File().PkgPath.Matches(), где m - это dsl.Matcher, насколько понял он появился через ~2 месяца после твоего issue и по моим небольшим локальным тестам метод должен помочь, если не сложно можешь проверить на своих данных и дать фидбек здесь или в https://t.me/go_critic_ru?
Пример использования можно посмотреть тут:
https://github.com/quasilyte/go-ruleguard/blob/003e476add1338428d96be12d3cc24b99c955b60/analyzer/testdata/src/filtertest/rules.go#L168
Единственное, метод не будет работать, если решишь его протестировать, как описано в 4 приеме, через golang.org/x/tools/go/analysis/analysistest, так как библиотека до сих пор не имеет поддержки модулей. Если не ошибаюсь проблема описана тут: https://github.com/golang/go/issues/37054.
Спасибо вам обоим с@quasilyteза ответы. Вероятно, пришло время мне снова попробовать активно использовать ruleguard (только надо дождаться следующего релиза golangci-lint). Ну и на версию с quasigo и dsl v1 будет очень интересно посмотреть, когда она выйдет.
Анализ синтаксиса, который всегда с тобой