Обновление из основного репозитория

…LibraryEntriesInCompletion

Подготовка к task #2 (hover + Go to Def для internal-классов библиотек).

- LibraryEntry получает boolean implicit (default false для существующих
  записей из manifest/convention).
- OScriptLibraryIndex.registerEntry: package-private перегрузка с явным
  implicit-флагом; старая private-перегрузка делегирует с false.
- OScriptOptions.showImplicitLibraryEntriesInCompletion (JSON-ключ
  oscript.showImplicitLibraryEntriesInCompletion), default false.
- CompletionProvider: фильтр для no-dot completion (включая блок после
  "Новый ", библиотечные классы и global contexts) — implicit-записи
  скрываются, если флаг выключен.

Тесты:
- OScriptOptionsTest: дефолт false, сеттер тоглит.
- ImplicitEntryCompletionFilterTest (3 кейса): default скрывает,
  включённый флаг показывает, публичные не задеты фильтром.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

…транзитивных oscript_modules

C2 для task #2: при индексации библиотеки через lib.config найти все .os в
convention-каталогах (Классы/Classes/Модули/Modules) на любой глубине и
зарегистрировать необъявленные в манифесте записи как implicit=true. Это
закрывает потребительский сценарий: internal-классы зависимости попадают
в TypeRegistry/ReferenceIndex (полноценные hover/Go to Def через основной
manifest-канал) и при этом скрываются из no-dot completion фильтром из C1.

- OScriptLibraryIndex.indexLibrary: после обработки manifest вызывает
  collectImplicitEntries(libRoot, libOrigin, serverContext) — Files.walkFileTree
  с глубиной 8, скипает каталоги oscript_modules через preVisitDirectory
  SKIP_SUBTREE, регистрирует .os в convention-каталогах через
  registerEntry(..., implicit=true). Уже зарегистрированные URI пропускает
  по entriesByUri.containsKey, чтобы не дублировать manifest-записи.
- LibConfigDiscovery.scan: preVisitDirectory скипает oscript_modules при
  поиске lib.config — транзитивные зависимости
  (oscript_modules/dep/oscript_modules/transitive/lib.config) больше не
  попадают в индекс верхнего workspace. Корневой workspace/oscript_modules/<lib>
  обрабатывается отдельно через addOscriptModulesChildren — этот путь не задет.
- ConventionalLibraryDiscovery: CLASS_DIRS, MODULE_DIRS, OS_SUFFIX повышены
  до public, чтобы OScriptLibraryIndex.collectImplicitEntries делил с ним
  единый источник convention-имён.

Тесты:
- OScriptLibraryIndexImplicitDiscoveryTest (3 кейса):
  manifest-записи остаются implicit=false; .os в src/internal/Классы
  подцепляется как implicit CLASS; .os вне convention-каталогов не задевается.
- NestedOscriptModulesSkipTest: двухуровневая fixture
  workspace/oscript_modules/direct-dep/oscript_modules/transitive-dep —
  DirectClass в индексе, TransitiveClass нет.
- fixture implicit-test пополнена AutoFound.os под src/internal/Классы/.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

…skip oscript_modules в convention-walk

C3 для task #2 и task #3: convention-обнаруженные библиотеки (без lib.config)
тоже сканируются рекурсивно на необъявленные .os в convention-каталогах.
Это закрывает:
- workspace разработчика autumn: всё под src/internal/Классы, src/Модули,
  src/<подсистема>/Классы попадает в индекс. При
  oscript.showImplicitLibraryEntriesInCompletion=true разработчик получает
  internal-классы в no-dot completion в своём же проекте.
- multi-package layout (opentelemetry-style): src/<подсистема>/Классы/*.os
  тоже подбираются как implicit, даже без lib.config.

- OScriptLibraryIndex.indexConventional: после регистрации classFiles/moduleFiles
  из ConventionalLibrary вызывает collectImplicitEntries(lib.root(), ...) —
  тот же helper, что в indexLibrary (C2). URI, уже зарегистрированные
  top-level convention'ом, пропускаются по entriesByUri.containsKey.
- ConventionalLibraryDiscovery.walk: при рекурсивном обходе фильтрует
  каталоги oscript_modules — транзитивные зависимости не должны
  открываться как самостоятельные convention-библиотеки.

Тесты:
- ConventionalLibraryImplicitDiscoveryTest (3 кейса): top-level Классы/Модули
  остаются explicit; src/internal/Классы подцепляется как implicit CLASS;
  oscript_modules внутри обнаруженной convention-библиотеки пропускается.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

…тает

Закрыты оба root-cause'а runtime-зависания, обнаруженные при native-`analyze`.
Это были два кооперирующихся бага в нашем коде, **не SVM** — на JVM они
существуют, но не триггерятся.

## Root cause #1: Spring AOT не вызывает @Autowired-setter'ы для prototype-бинов
`CyclomaticComplexityComputer` и `CognitiveComplexityComputer` (оба prototype,
создаются через `ObjectProvider.getObject(documentContext)`) имели
`@Setter(onMethod_={@Autowired}) StringInterner stringInterner` — тот же AOT-баг,
который мы уже фиксили в `DocumentContext`: chained `andThen(__Autowiring::apply)`
в native не отрабатывает. Поле `stringInterner` оставалось `null` → NPE на
`stringInterner.intern(...)` внутри `addSecondaryLocation`.

Фикс: setter сделан public, `DocumentContext` после `getObject(...)` вызывает
`computer.setStringInterner(stringInterner)` вручную. Сам stringInterner
приезжает через `ServerContext` (constructor inject) → передаётся в
`DocumentContext.initializeDependencies(...)`.

## Root cause #2: Lazy.getOrCompute теряет lock на исключении
В `io.github.1c-syntax:utils:0.7.0/com/github/_1c_syntax/utils/Lazy.java:60-68`
{@code lock.unlock()} стоит после {@code maybeCompute(supplier)} вне try/finally:

```java
public T getOrCompute(Supplier<T> supplier) {
    final T result = value;
    if (result == null) {
      lock.lock();
      var localResult = maybeCompute(supplier);  // exception → unlock пропущен
      lock.unlock();
      return localResult;
    }
    return result;
}
```

Любое исключение в `supplier.get()` оставляет lock захваченным навсегда.
В `DocumentContext` несколько `Lazy<>` шарят общий `computeLock`
(`contentList`, `moduleType`, `cognitiveComplexityData`, `cyclomaticComplexityData`,
`diagnosticIgnoranceData`, `metrics`). После NPE в `computeCyclomaticComplexity`
(root cause #1) lock остаётся занятым, все следующие обращения к
`getAst`/`getSymbolTree` ([@locked]("computeLock") от Lombok) виснут.

Лечится shadow-копией `Lazy` в нашем `src/main/java` с `lock.unlock()` в
`finally` (классическая корректная реализация). Подменяется через стандартный
classloader-precedence. На JVM баг тоже потенциально опасен, но в нашем
рантайме там не было исключений в supplier'ах computeLock-ассоциированных
Lazy → не триггерилось.

## Дополнительно: hints
- `net/loomchild/segment/**` resource-globs (нужны LanguageTool для парсинга SRX);
- 82 класса `com.contrastsecurity.sarif.*` с `allDeclaredFields`/`Constructors`/`Methods` —
  без них Jackson 3 сериализатор тихо отдавал пустой `{}` SARIF.

## Подтверждение и бенч

`./build/native/nativeCompile/bsl-language-server analyze --srcDir ~/ssl_3_2/src/cf --reporter sarif --outputDir /tmp/out`:

|                    | JVM (java -jar exec) | Native (executable) |
|--------------------|----------------------|---------------------|
| Время              | 5m29s                | **2m10s**           |
| Размер бинаря      | 103 MB (exec.jar)    | 140 MB              |
| Размер SARIF       | 267 MB               | 258 MB              |
| Холодный старт     | ~3 c                 | ~0.2 c              |

Native в **~2.5x быстрее JVM** на анализе 2175 файлов 1С-конфигурации
ssl_3_2 — и это без специальных оптимизаций образа
(`-march=native`, `-O3`, профильная компиляция). Холодный старт CLI-команды
(version/--help) на native ~200мс, на JVM ~3с — выигрыш на коротких
вызовах ещё больше.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

…сь модуль (#2)

getSemanticTokensRange гонял ВСЕ сапплаеры по всему документу и фильтровал
результат постфактум — дорогой memberAt per-call-site отрабатывал для всего
модуля (~190с на 47k строк), даже если клиент запросил видимое окно.

- SemanticTokensSupplier: default-перегрузка getSemanticTokens(dc, Range);
  по умолчанию отдаёт полный набор (провайдер его триммит), дорогие сапплаеры
  переопределяют.
- SemanticTokensProvider.getSemanticTokensRange зовёт collectTokens(dc, range),
  пробрасывая диапазон в сапплаеры.
- PlatformMemberProperty/MethodCall: пред-фильтр по Ranges.containsPosition
  ПЕРЕД memberAt — тяжёлый инференс только для узлов в окне.

Замер на УправлениеДоступомСлужебный (SSL, 47k строк), окно 60 строк:
property 195985ms → 83ms, method 184385ms → 102ms (~1900×). Поведение
проверено тестами (range-перегрузка возвращает только токены окна).

Co-Authored-By: Claude Opus 4.8 <[email protected]>

…vider

Рефактор (задача 1c-syntax#1): инференсер больше не обращается к двум URI-ключевым
подсистемным индексам (oScriptLibraryIndex + ConfigurationModuleMembersProvider)
ради восстановления типа ресивера-модуля. Тип теперь берётся из единого
обратного индекса URI→TypeRef в GlobalScopeProvider.

Почему так: GlobalScopeProvider уже владеет обоими типами модулей по ИМЕНИ
(общий модуль — PLATFORM_GLOBAL_PROPERTY, library — LIBRARY_MODULE), но у
inferSymbol(ModuleSymbol) на руках URI, а не имя — не хватало обратного
lookup'а у самого авторитета, и его обходили через чужие индексы.

- GlobalScopeProvider: indexModuleType/removeModuleType/moduleTypeByUri(URI).
- Писатели — те же провайдеры регистрации модулей, синхронно рядом с
  регистрацией имени (URI у них на руках): общий/менеджер/объектный модуль
  (ConfigurationModuleMembersProvider) и library-модуль (OScriptModuleMembersProvider);
  снятие library — в его unregister(uri).
- ExpressionTypeInferencer.inferModuleAsType — один вызов moduleTypeByUri;
  удалены зависимости OScriptLibraryIndex и ConfigurationModuleMembersProvider
  (минус 2 коллаборатора, задача 1c-syntax#2), снят мёртвый typeForUri (1c-syntax#3991).

Race-safety: обновления синхронные (event-листенеры не @async), в тех же
хендлерах, ConcurrentHashMap; переименование — перезапись по URI; удаление
library — remove(uri). Общий модуль без листенера удаления и reindex
библиотек протекают ровно как существующий name-индекс (паритет, не регресс).

Тест: lifecycle обратного индекса (register→present, unregister→cleared).

Co-Authored-By: Claude Opus 4.8 <[email protected]>

ReferenceIndexMemoryTest полностью наполняет реальный reference-индекс
конфигурации (по умолчанию SSL 3.2) и через JOL сравнивает retained-память
трёх вариантов SymbolOccurrenceRepository над одними и теми же объектами
обращений (разница = чистый overhead контейнера):
A skiplist/skiplist (прод), B hash/newKeySet (#2), C hash/skiplist-inner
(гибрид). Печатает распределение размеров внутренних множеств — оно и
объясняет overhead.

На реальном индексе (177k символов, 631k обращений, 39% синглтонов):
B даёт +1.3% памяти, гибрид C — -1.4% при том же выигрыше по скорости и
сохранении порядка обращений.

build.gradle.kts: jol-core в testImplementation, -Djol.magicFieldOffset=true
в тест-форк под флагом bsl.profile (JOL читает оффсеты полей record-ов).

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01HcK3qVwTH91rXtgprGmoWr