есть библиотека, которая использует аннотации из Котлин компайлер плагина. Впервые понадобилось выяснить, откуда я прихожу в методы из плагина.
Когда я дебажу его в идее - я не могу получить полный стек вызовов. Вместо этого получаю просто ссылку на аннотации (которые используются плагином для генерации кода) у себя в стеке.
./gradlew --no-daemon -i -Dorg.gradle.debug=true -Dkotlin.compiler.execution.strategy=in-process И приаттачится дебагером к процессу гредла.
Потрясающе, не ожидал ответа здесь, тем более такого быстрого )
Уверен что когда-нибудь мне это пригодится, но потом я не вспомню как это найти в истории чата..
Как дебажить компиляторный плагин? #компиляторный_плагин теперь не потеряется )
Потому я положил себе это в сохранёнки, чтобы не смочь со временем найти там, а не тут!
а теперь время тупых вопросов - а что если проскальзывает дебаг? Спокойно подключается к таске, но идея игнорирует брейкпоинты, хотя висящая гредл таска, ожидавшая дебаггера начинает работать и спокойно проходит до конца. То есть к таске подключаюсь, но брейкпоинтов, установленных через идею - не видит. Нужен какой-то особенный дебагер или особенные BP, остановленные не через Идею? Пользуюсь обычной комьюнити едишен, дебажу Kotlin-jvm
Это значит, что гредл игнорирует флаги в всё равно запускает демон компилятора. Возможно, ему не хватает памяти. Можно попробовать увеличить -Xmx и -Xms и перезапустить.
Я возможно что-то не то делаю, но я попробовал уже и память увеличить и все равно не помогает. Проскальзывает мимо брейкпоинтов. Если вкратце: у меня есть конкретный kotlin test, в котором я вызываю имплементацию своего компиляторного плагина (для serialization). 1) я вызываю gradle :ktoml-core:cleanJvmTest :ktoml-core:jvmTest --tests "com.akuleshov7.ktoml.decoders.InlineDecoderTest" --no-daemon -i -Dorg.gradle.debug=true -Dkotlin.compiler.execution.strategy=in-process (возможно это бред - вызывать это на тест?) 2) БП ставлю в этом тесте и в своем коде имплементации компиляторного плагина Может быть нельзя именно тест вызывать, но с build бесполезно вызывать это, потому что я хочу получить стек именно У СЕБЯ в коде до момента самого компиляторного плагина. Были еще мысли о том, что проблема в самих флагах, которые глотает gradle, но я попробовал И с export GRADLE_OPTS И с gradle.properties. То есть флаги пробрасываются и работают.
Компиляторный плагин работает во время компиляции. Поэтому если компилятор не вызывается, то есть, если уже всё собрано и сборка не нужна, компилятор не вызывается и соответственно, компиляторный плагин тоже не исполняется. Невозможно получить стек вызовов в своём коде, так как, опять-таки, компиляторный плагин работает во время компиляции.
Да, но в стеке вызовов в имплементации базовых интерфейсов Decoder/Encoder из компиляторного плагина ведь должен быть стек к базовым методам serialization core? Как иначе дебажить кастомные декодеры/енкодеры?
Мне кажется, Ильмир намекает, что есть смысл сделать таску, отвечающую за сборку интересующего модуля, в гредле постоянно грязной, дабы она гарантированно перевызывалась каждый раз.
Да нет, я же клин делаю. Речь не о чистом билде. Он каждый раз перезапускается в тесте. Ильмир говорит о невозможности построения на вызове дебага юнит-теста стека, ведущего к компиляторному плагину, потому что это разные фазы.
А, по поводу клина упустил. Тогда я не в тему.
Ни на build, ни если запускать тест, как я выше написал в пункте 1
Обсуждают сегодня