Fix trailing variable description links and semantic token positions#4165
Conversation
…переменных В описаниях переменных, заданных висячим (trailing) комментарием, не работали два механизма, потому что такие комментарии начинаются не с начала строки. Семантические токены (BslDocSemanticTokensSupplier): позиции элементов (типы, имена параметров, ключевые слова) приходят от парсера в абсолютных координатах файла, но к ним повторно прибавлялся отступ описания (charOffset). Из-за двойного смещения подсветка типов «съезжала» вправо в любом описании, которое не начинается со столбца 0 (висячие комментарии и комментарии, ставшие описанием следующего метода). Теперь обработка строки ведётся в абсолютных координатах без повторного прибавления отступа. Document links (SeeReferenceDocumentLinkSupplier): ссылки «См.» из висячего описания переменной хранятся в отдельном VariableDescription (getTrailingDescription) и не попадают в getLinks() основного описания, поэтому кликабельные ссылки не создавались. Теперь висячее описание обходится явно. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_016DL8j9ZCc6WCiKeL4uMBFs
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughTwo independent improvements in BSL documentation processing: document link extraction is extended to variable trailing descriptions and a new type-definition document link supplier is added; semantic token emission for variables now validates type resolution and uses absolute character coordinates, eliminating double-offset shifts for indented descriptions. ChangesDocument links for trailing references and type definitions
Semantic token type validation and coordinate system
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…писаниях bsl-parser 0.37.0 отдаёт TYPE_NAME-элемент для типа переменной (нотация «тип в начале»: первый токен до « - »). Благодаря исправлению координат в BslDocSemanticTokensSupplier тип теперь корректно подсвечивается и в висячих (trailing) комментариях, и в ведущих описаниях переменных. Тесты: - BslDocSemanticTokensSupplierTest: тип «Строка» в висячем комментарии переменной подсвечивается как Type на реальной позиции; - SemanticTokensProviderTest.variableDescriptionComments: первый токен висячего описания теперь трактуется как тип (актуализированы ожидаемые токены). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_016DL8j9ZCc6WCiKeL4uMBFs
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@build.gradle.kts`:
- Line 99: The bsl-parser dependency in build.gradle.kts is using version 0.37.0
which does not exist. Update the api dependency declaration for
io.github.1c-syntax:bsl-parser by changing the version string from 0.37.0 to
0.35.0, which is the latest available version as of June 2026. Ensure the
dependency line reads api("io.github.1c-syntax:bsl-parser:0.35.0").
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 8e442f92-9262-4ebc-aa7c-3df1d92942d6
📒 Files selected for processing (3)
build.gradle.ktssrc/test/java/com/github/_1c_syntax/bsl/languageserver/providers/SemanticTokensProviderTest.javasrc/test/java/com/github/_1c_syntax/bsl/languageserver/semantictokens/BslDocSemanticTokensSupplierTest.java
🚧 Files skipped from review as they are similar to previous changes (1)
- src/test/java/com/github/_1c_syntax/bsl/languageserver/semantictokens/BslDocSemanticTokensSupplierTest.java
…сли он резолвится Тип переменной берётся из первого токена описания (нотация «тип в начале»), поэтому любой свободный текст в висячем комментарии (// трейл, // счётчик ...) парсер отдаёт TYPE_NAME-элементом. Чтобы не подсвечивать как тип произвольные слова, BslDocSemanticTokensSupplier теперь проверяет резолв имени через TypeService и красит элемент как Type только при успешном резолве. Проверка применяется только к описаниям переменных (ведущим и висячим). Типы параметров/возврата в описаниях методов задаются структурно и подсвечиваются без проверки — иначе конфигурационные типы теряли бы подсветку без загруженных метаданных. Тесты: - BslDocSemanticTokensSupplierTest: нерезолвящийся первый токен висячего комментария не подсвечивается как тип (остаётся комментарием); - SemanticTokensProviderTest.variableDescriptionComments: возврат к одному токену-комментарию для «// трейл». Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_016DL8j9ZCc6WCiKeL4uMBFs
Имена типов в doc-комментариях (типы параметров/возврата методов и тип переменной по нотации «тип в начале») теперь становятся кликабельными document link на объявление типа. Новый TypeDefinitionDocumentLinkSupplier обходит TYPE_NAME-элементы описаний методов и переменных (включая висячие), резолвит имя через TypeService и, если у типа есть объявляющий исходный символ (TypeService.definingSymbol — USER/CONFIGURATION), формирует ссылку на его местоположение. Платформенные и примитивные типы объявляющего символа не имеют и пропускаются; это же служит гвардом для описаний переменных — произвольный текст в висячем комментарии не резолвится в тип и ссылку не порождает. Также поднята зависимость bsl-parser до 0.37.1. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_016DL8j9ZCc6WCiKeL4uMBFs
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/test/java/com/github/_1c_syntax/bsl/languageserver/documentlink/TypeDefinitionDocumentLinkSupplierTest.java (1)
77-104: 💤 Low valueConsider adding range assertion for completeness.
The test verifies the link target but not the range. Adding a range assertion would make the test more thorough and help catch potential regressions in coordinate handling for trailing descriptions.
💡 Optional enhancement
// then assertThat(documentLinks) .hasSize(1) .first() - .satisfies(documentLink -> + .satisfies(documentLink -> { + assertThat(documentLink.getRange()).isEqualTo(Ranges.create(1, 17, 23)); assertThat(documentLink.getTarget()).isEqualTo(symbolTarget(documentContext, targetSymbol.getSelectionRange())) - ); + });Note: Verify the exact range values match the parsed element coordinates.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/test/java/com/github/_1c_syntax/bsl/languageserver/documentlink/TypeDefinitionDocumentLinkSupplierTest.java` around lines 77 - 104, In the trailingVariableTypeWithSourceSymbolProducesLink test method, add a range assertion to verify the document link's range coordinates in addition to the target assertion. Within the satisfies callback block where you currently assert documentLink.getTarget(), add an additional assertion to verify that documentLink.getRange() matches the expected range of the "МойТип" text in the trailing comment. This will ensure both the target location and the range coordinates are correctly handled for trailing variable type descriptions.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In
`@src/test/java/com/github/_1c_syntax/bsl/languageserver/documentlink/TypeDefinitionDocumentLinkSupplierTest.java`:
- Around line 77-104: In the trailingVariableTypeWithSourceSymbolProducesLink
test method, add a range assertion to verify the document link's range
coordinates in addition to the target assertion. Within the satisfies callback
block where you currently assert documentLink.getTarget(), add an additional
assertion to verify that documentLink.getRange() matches the expected range of
the "МойТип" text in the trailing comment. This will ensure both the target
location and the range coordinates are correctly handled for trailing variable
type descriptions.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 733065e9-c79c-401f-99ab-ab04903457ae
📒 Files selected for processing (3)
build.gradle.ktssrc/main/java/com/github/_1c_syntax/bsl/languageserver/documentlink/TypeDefinitionDocumentLinkSupplier.javasrc/test/java/com/github/_1c_syntax/bsl/languageserver/documentlink/TypeDefinitionDocumentLinkSupplierTest.java
🚧 Files skipped from review as they are similar to previous changes (1)
- build.gradle.kts
Добавлена проверка range у document link для типа в висячем комментарии переменной (помимо target) — страхует корректность координат для trailing-описаний. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_016DL8j9ZCc6WCiKeL4uMBFs
|
…координат Вместо восстановления текста типа по координатам элемента описания используются семантические аксессоры bsl-parser, дающие идентичность типа для резолва: MethodDescription.getParameters()/getReturnedValue(), VariableDescription.getTypes() → TypeDescription.name() (SIMPLE) и CollectionTypeDescription.collectionName() (COLLECTION, т.к. name() отдаёт полную запись «Массив<Число>»). Общая логика вынесена в утилиту DescriptionTypes (typesOf/resolveName). Убраны дублирующиеся помощники извлечения текста по координатам (typeName в BslDocSemanticTokensSupplier и elementText в TypeDefinitionDocumentLinkSupplier): - подсветка типа переменной теперь решается по множеству резолвящихся диапазонов типов (element().range()); - document link на тип строится по name()/collectionName() и element().range(). Поведение не меняется — тесты подсветки и document link остаются зелёными. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_016DL8j9ZCc6WCiKeL4uMBFs



Описание
Исправлены два связанных бага при обработке висячих (trailing) комментариев после объявления переменных:
Ссылки в висячих комментариях переменных не обрабатывались: Висячий комментарий (например,
Перем П; // См. ДругойМетод) хранится в отдельномVariableDescriptionчерез методgetTrailingDescription(), но эти ссылки не попадали в обработку. Добавлена рекурсивная обработка висячих описаний в методеaddLinksFromDescription().Неправильное позиционирование семантических токенов в висячих комментариях: При обработке элементов описания, начинающегося не с начала строки, происходило двойное смещение позиций (прибавление
charOffsetк уже абсолютным координатам от парсера). Исправлена логика вaddBslDocTokensForLine()для работы с абсолютными координатами файла.Изменения:
addLinksFromDescription(), который рекурсивно обрабатывает висячие описания переменныхСвязанные задачи
Closes
Чеклист
Общие
Дополнительно
Добавлены два новых теста:
testTrailingVariableDescriptionReferenceProducesLink()— проверяет, что ссылки в висячих комментариях переменных корректно обрабатываютсяtestElementsInDescriptionStartingAtNonZeroColumn()— проверяет корректное позиционирование семантических токенов в описаниях, начинающихся не с начала строкиhttps://claude.ai/code/session_016DL8j9ZCc6WCiKeL4uMBFs
Summary by CodeRabbit