refactor(references): разорвать цикл references↔types через унификацию OScript-резолва по mdoRef#4233
refactor(references): разорвать цикл references↔types через унификацию OScript-резолва по mdoRef#4233nixel2007 wants to merge 4 commits into
Conversation
…ences KeywordReferenceFinder, NewExpressionReferenceFinder and PlatformMemberReferenceFinder resolve references by consulting the type system (TypeService, GlobalScopeProvider, type symbols) — they are type-aware adapters of the ReferenceFinder port, not part of the type-agnostic name-resolution core. The port (ReferenceFinder) and the pure finders stay in `references`; these three move to `types.references`, next to their dependencies, so `references` no longer depends on `types` through them. They keep implementing references.ReferenceFinder and are still collected by ReferenceResolver via List<ReferenceFinder> (Spring, package-independent). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LkYRgB6NZZRRNZmBrdL54M
…oRef unification The last references→types edge was ReferenceIndexFiller depending on types.oscript.OScriptLibraryIndex to map an OScript library class/module name to its file URI (used as the reference mdoRef). BSL references resolve differently: the filler computes a logical mdoRef from metadata via context (MdoRefBuilder/findCommonModule) and resolves through ServerContext.getDocument(mdoRef, moduleType). OScript was the odd one out, keying by URI because .os library docs had no logical mdoRef. Unify OScript onto the same path: - ServerContext gains a workspace-level catalog of OScript library symbols (name → canonical name + ModuleType + URI), case-insensitive, with findLibraryClass/findLibraryModule — parallel to findCommonModule and using only context-safe types (no dependency on the `types` package). - OScriptLibraryIndex populates the catalog (types→context) during reindex and registerEntry, and clears/removes it in lockstep with its own entries. - .os documents are additionally registered in documentsByMDORef under each of their canonical library names, so getDocument(name, moduleType) resolves them — multi-identity (one file, several library names/roles) is handled by registering the doc under each name. The BSL registration path (addMdoRefByUri / mdoRefs) is untouched. - ReferenceIndexFiller now canonicalizes via ServerContext.findLibrary…, uses the canonical name as mdoRef and the syntactic ModuleType, and drops OScriptLibraryIndex and actualLibraryModuleType — so references no longer depends on types. The ArchitectureTest model is updated accordingly (References no longer accesses Types; only types→references remains). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LkYRgB6NZZRRNZmBrdL54M
WalkthroughServerContext now tracks canonical OneScript library names and symbols. OScriptLibraryIndex registers, removes, and clears those mappings as library documents change. ReferenceIndexFiller resolves library references through ServerContext, and type-aware reference classes move into ChangesOScript library catalog and reference resolution
Estimated code review effort: 4 (Complex) | ~60 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/main/java/com/github/_1c_syntax/bsl/languageserver/references/ReferenceIndexFiller.java (1)
571-572: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRename the URI-named library-class flow to mdoRef.
findLibraryClass(...)now returns the canonical mdoRef, but this value still flows throughvariableToLibraryClassUriMap,libClassUri, and comments that say URI. Rename these to...MdoRef...to keep the new ServerContext contract explicit.🤖 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/main/java/com/github/_1c_syntax/bsl/languageserver/references/ReferenceIndexFiller.java` around lines 571 - 572, The library-class lookup in ReferenceIndexFiller should be renamed to reflect the new canonical mdoRef value instead of URI. Update the flow around findLibraryClass(...) and the related variable/method names such as variableToLibraryClassUriMap and libClassUri so they use MdoRef naming consistently, and adjust any comments or local symbols that still describe the value as a URI.
🤖 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
`@src/main/java/com/github/_1c_syntax/bsl/languageserver/context/ServerContext.java`:
- Around line 128-130: `ServerContext` currently indexes `OScriptLibrarySymbol`
only by `nameKey`, so a library exported as both module and class can overwrite
one entry and break `findLibraryClass(...)` or `findLibraryModule(...)`. Update
the `oscriptLibrariesByNameKey` / `oscriptLibraryNameKeysByUri` storage and the
related registration and cleanup flow in `ServerContext` to key symbols by both
name and module type (for example, via a composite key or nested map) so both
variants can coexist. Also make removal URI-aware and exact to the stored symbol
key so cleanup does not unregister a replacement from another URI sharing the
same `nameKey`.
---
Nitpick comments:
In
`@src/main/java/com/github/_1c_syntax/bsl/languageserver/references/ReferenceIndexFiller.java`:
- Around line 571-572: The library-class lookup in ReferenceIndexFiller should
be renamed to reflect the new canonical mdoRef value instead of URI. Update the
flow around findLibraryClass(...) and the related variable/method names such as
variableToLibraryClassUriMap and libClassUri so they use MdoRef naming
consistently, and adjust any comments or local symbols that still describe the
value as a URI.
🪄 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: fad3e7ec-63b5-424e-9855-94a5c0f65ff0
📒 Files selected for processing (8)
src/main/java/com/github/_1c_syntax/bsl/languageserver/context/ServerContext.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/references/ReferenceIndexFiller.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/types/oscript/OScriptLibraryIndex.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/types/references/KeywordReferenceFinder.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/types/references/NewExpressionReferenceFinder.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/types/references/PlatformMemberReferenceFinder.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/types/references/package-info.javasrc/test/java/com/github/_1c_syntax/bsl/languageserver/architecture/ArchitectureTest.java
Test Results 3 582 files 3 582 suites 1h 31m 40s ⏱️ Results for commit 4687137. ♻️ This comment has been updated with latest results. |
…not generic doc lifecycle The first cut registered .os documents in documentsByMDORef via a hook in the generic createDocumentContext/removeDocument paths (fired for every document, BSL included, no-op for non-OScript) and kept a URI→names reverse map in ServerContext to make that hook cheap. That leaked OScript-specific logic into the generic document lifecycle. OScriptLibraryIndex already owns the .os document lifecycle (it creates and removes them in registerEntry/handleDocumentRemoved and has its own URI→entries index). So drive the documentsByMDORef registration from there: ServerContext now exposes only registerOScriptLibrary(name, moduleType, doc) and removeOScriptLibrary(name, moduleType) (catalog entry + documentsByMDORef key together), the index calls them per entry, and the generic createDocumentContext/removeDocument hooks and the URI→names reverse map are gone. ServerContext keeps just the case-insensitive name catalog (the findLibraryClass/Module canonicalizer). No behaviour change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LkYRgB6NZZRRNZmBrdL54M
There was a problem hiding this comment.
♻️ Duplicate comments (1)
src/main/java/com/github/_1c_syntax/bsl/languageserver/context/ServerContext.java (1)
128-128: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winKey the OScript catalog by both normalized name and
ModuleType.This still stores only one symbol per
nameKey, so registering the same library name as bothOScriptClassandOScriptModuleoverwrites one variant. After that, eitherfindLibraryClass(...)orfindLibraryModule(...)can start returning empty incorrectly, andremoveOScriptLibrary(...)removes by name only, so it can also drop the surviving variant. A composite key like(nameKey, moduleType)or a nested map fixes both problems.Also applies to: 493-544
🤖 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/main/java/com/github/_1c_syntax/bsl/languageserver/context/ServerContext.java` at line 128, The OScript library cache in ServerContext is keyed only by the normalized name, so registering the same library as both OScriptClass and OScriptModule overwrites one entry and makes findLibraryClass(...), findLibraryModule(...), and removeOScriptLibrary(...) behave incorrectly. Update oscriptLibrariesByNameKey to use a composite key or nested map that includes both nameKey and ModuleType, and adjust the lookup and removal logic in findLibraryClass(...), findLibraryModule(...), and removeOScriptLibrary(...) so each variant is stored, found, and removed independently.
🤖 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.
Duplicate comments:
In
`@src/main/java/com/github/_1c_syntax/bsl/languageserver/context/ServerContext.java`:
- Line 128: The OScript library cache in ServerContext is keyed only by the
normalized name, so registering the same library as both OScriptClass and
OScriptModule overwrites one entry and makes findLibraryClass(...),
findLibraryModule(...), and removeOScriptLibrary(...) behave incorrectly. Update
oscriptLibrariesByNameKey to use a composite key or nested map that includes
both nameKey and ModuleType, and adjust the lookup and removal logic in
findLibraryClass(...), findLibraryModule(...), and removeOScriptLibrary(...) so
each variant is stored, found, and removed independently.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 4f85bf7c-b0ce-41d5-a0a8-1b3fd6929358
📒 Files selected for processing (2)
src/main/java/com/github/_1c_syntax/bsl/languageserver/context/ServerContext.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/types/oscript/OScriptLibraryIndex.java
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/java/com/github/_1c_syntax/bsl/languageserver/types/oscript/OScriptLibraryIndex.java
…dule Complete the OScript mdoRef unification: a library .os document's mdoRef is now its canonical library name (not the URI), so it is indexed in documentsByMDORef under its own mdoRef — uniformly with BSL objects. ServerContext.findLibraryClass/findLibraryModule now return the resolved DocumentContext instead of the canonical name string; callers get the doc directly and read the reference-index key from doc.getMdoRef(), dropping the extra getDocument(mdoRef, moduleType) round-trip in ReferenceIndexFiller. The library name is seeded into ServerContext (registerOScriptLibraryName) before the document is added, so MdoRefBuilder resolves the mdoRef of an .os file without an MD object to that name. Also fix three dangling javadoc @link references to KeywordReferenceFinder, left in context.symbol/hover/providers after the finder moved to types.references. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LkYRgB6NZZRRNZmBrdL54M
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/main/java/com/github/_1c_syntax/bsl/languageserver/types/oscript/OScriptLibraryIndex.java (2)
141-143: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winClear prior registrations from
entriesByUri, notentriesByName.Line 142 iterates the collapsed
entriesByNamemap. For a.osfile exported under the same name as both module and class, only one entry is removed fromServerContext, leaving the otherdocumentsByMDORefregistration stale across reindex.Proposed fix
- entriesByName.values().forEach(entry -> - serverContext.removeOScriptLibrary(entry.qualifiedName(), moduleTypeOf(entry.kind()))); + entriesByUri.values().stream() + .flatMap(Collection::stream) + .forEach(entry -> + serverContext.removeOScriptLibrary(entry.qualifiedName(), moduleTypeOf(entry.kind())));🤖 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/main/java/com/github/_1c_syntax/bsl/languageserver/types/oscript/OScriptLibraryIndex.java` around lines 141 - 143, The cleanup in OScriptLibraryIndex should remove all prior registrations from ServerContext using entriesByUri, not the collapsed entriesByName map. Update the reindex cleanup loop to iterate the URI-indexed entries so both module and class registrations are cleared, and keep using serverContext.removeOScriptLibrary with each entry’s qualifiedName() and moduleTypeOf(entry.kind()).
428-453: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winRollback the URI→library-name binding on load failure.
Line 431 registers the canonical name before the
try, but thecatchonly logs. IfaddDocumentorrebuildDocumentfails,ServerContext.findOScriptLibraryName(uri)remains populated for an unregistered library andputIfAbsentcan block a corrected name on a later reindex.Proposed direction
- serverContext.registerOScriptLibraryName(uri, qualifiedName); - // Добавляем .os-файл в ServerContext как обычный документ. SymbolTreeComputer, ... try { + serverContext.registerOScriptLibraryName(uri, qualifiedName); var dc = serverContext.addDocument(uri); serverContext.rebuildDocument(dc); ... } catch (RuntimeException e) { + serverContext.removeOScriptLibraryName(uri, qualifiedName); LOGGER.warn("Failed to load oscript library file: {}", osFile, e); }🤖 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/main/java/com/github/_1c_syntax/bsl/languageserver/types/oscript/OScriptLibraryIndex.java` around lines 428 - 453, The URI-to-library-name mapping is being registered before the load work succeeds, so a failed load leaves stale state in ServerContext. In OScriptLibraryIndex around registerOScriptLibraryName/addDocument/rebuildDocument, move the binding into the successful path or explicitly undo it in the RuntimeException catch so a failed library load does not keep findOScriptLibraryName(uri) populated. Make sure the cleanup restores the pre-load state before logging the warning.
♻️ Duplicate comments (1)
src/main/java/com/github/_1c_syntax/bsl/languageserver/context/ServerContext.java (1)
129-129: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winKeep OneScript catalog entries keyed by both name and module type.
Line 531 still overwrites
oscriptLibrariesByNameKeybynameKeyonly. When the same library name is exported as both<module>and<class>, the later registration hides the earlier one, so eitherfindLibraryClass(...)orfindLibraryModule(...)returns empty; line 546 can also remove the wrong symbol. This matches the earlier catalog-keying concern and still appears present in the current code.Proposed direction
- private final Map<String, OScriptLibrarySymbol> oscriptLibrariesByNameKey = new ConcurrentHashMap<>(); + private final Map<OScriptLibrarySymbolKey, OScriptLibrarySymbol> oscriptLibrariesByKey = new ConcurrentHashMap<>(); ... - oscriptLibrariesByNameKey.put(oscriptNameKey(qualifiedName), new OScriptLibrarySymbol(moduleType, documentContext)); + var key = new OScriptLibrarySymbolKey(oscriptNameKey(qualifiedName), moduleType); + oscriptLibrariesByKey.put(key, new OScriptLibrarySymbol(moduleType, documentContext)); ... - var symbol = oscriptLibrariesByNameKey.remove(oscriptNameKey(qualifiedName)); + var symbol = oscriptLibrariesByKey.remove(new OScriptLibrarySymbolKey(oscriptNameKey(qualifiedName), moduleType)); ... - return Optional.ofNullable(oscriptLibrariesByNameKey.get(oscriptNameKey(name))) - .filter(symbol -> symbol.moduleType() == moduleType) + return Optional.ofNullable(oscriptLibrariesByKey.get(new OScriptLibrarySymbolKey(oscriptNameKey(name), moduleType))) .map(OScriptLibrarySymbol::documentContext); ... + private record OScriptLibrarySymbolKey(String nameKey, ModuleType moduleType) { + }Also applies to: 530-587
🤖 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/main/java/com/github/_1c_syntax/bsl/languageserver/context/ServerContext.java` at line 129, The OneScript library index in ServerContext is still keyed only by name, so entries for the same library can overwrite each other when one is a module and the other is a class. Update the registration and removal logic around oscriptLibrariesByNameKey to use a composite key that includes both the library name and module type, and make the lookup paths in findLibraryClass(...) and findLibraryModule(...) read from that same key scheme. Also ensure the cleanup code removes only the exact symbol that was registered so one variant does not delete the other.
🧹 Nitpick comments (1)
src/main/java/com/github/_1c_syntax/bsl/languageserver/references/ReferenceIndexFiller.java (1)
542-566: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRename the library-class “URI” plumbing to
mdoRef.Line 566 now stores
DocumentContext::getMdoRef, but the JavaDoc,variableToLibraryClassUriMap,libClassUri, andprocessLibraryClass...parameters still say URI. Please align the names/docs to avoid future misuse. As per coding guidelines: use meaningful Java names and keep documentation up to date.Also applies to: 613-620, 783-800
🤖 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/main/java/com/github/_1c_syntax/bsl/languageserver/references/ReferenceIndexFiller.java` around lines 542 - 566, Rename the library-class “URI” plumbing to mdoRef throughout ReferenceIndexFiller: update the JavaDoc on extractLibraryClassUriFromExpression, the variableToLibraryClassUriMap naming, the libClassUri local/parameter names, and the processLibraryClass... method parameters/usages so they consistently refer to mdoRef instead of URI. Also adjust any related comments and call sites in the referenced sections to keep the naming aligned with DocumentContext::getMdoRef and prevent misleading documentation.Source: Coding guidelines
🤖 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.
Outside diff comments:
In
`@src/main/java/com/github/_1c_syntax/bsl/languageserver/types/oscript/OScriptLibraryIndex.java`:
- Around line 141-143: The cleanup in OScriptLibraryIndex should remove all
prior registrations from ServerContext using entriesByUri, not the collapsed
entriesByName map. Update the reindex cleanup loop to iterate the URI-indexed
entries so both module and class registrations are cleared, and keep using
serverContext.removeOScriptLibrary with each entry’s qualifiedName() and
moduleTypeOf(entry.kind()).
- Around line 428-453: The URI-to-library-name mapping is being registered
before the load work succeeds, so a failed load leaves stale state in
ServerContext. In OScriptLibraryIndex around
registerOScriptLibraryName/addDocument/rebuildDocument, move the binding into
the successful path or explicitly undo it in the RuntimeException catch so a
failed library load does not keep findOScriptLibraryName(uri) populated. Make
sure the cleanup restores the pre-load state before logging the warning.
---
Duplicate comments:
In
`@src/main/java/com/github/_1c_syntax/bsl/languageserver/context/ServerContext.java`:
- Line 129: The OneScript library index in ServerContext is still keyed only by
name, so entries for the same library can overwrite each other when one is a
module and the other is a class. Update the registration and removal logic
around oscriptLibrariesByNameKey to use a composite key that includes both the
library name and module type, and make the lookup paths in findLibraryClass(...)
and findLibraryModule(...) read from that same key scheme. Also ensure the
cleanup code removes only the exact symbol that was registered so one variant
does not delete the other.
---
Nitpick comments:
In
`@src/main/java/com/github/_1c_syntax/bsl/languageserver/references/ReferenceIndexFiller.java`:
- Around line 542-566: Rename the library-class “URI” plumbing to mdoRef
throughout ReferenceIndexFiller: update the JavaDoc on
extractLibraryClassUriFromExpression, the variableToLibraryClassUriMap naming,
the libClassUri local/parameter names, and the processLibraryClass... method
parameters/usages so they consistently refer to mdoRef instead of URI. Also
adjust any related comments and call sites in the referenced sections to keep
the naming aligned with DocumentContext::getMdoRef and prevent misleading
documentation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 941ae410-841d-4a61-8671-4fda3c7c08ae
📒 Files selected for processing (7)
src/main/java/com/github/_1c_syntax/bsl/languageserver/context/MdoRefBuilder.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/context/ServerContext.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/context/symbol/KeywordSymbol.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/hover/KeywordSymbolMarkupContentBuilder.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/providers/HoverProvider.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/references/ReferenceIndexFiller.javasrc/main/java/com/github/_1c_syntax/bsl/languageserver/types/oscript/OScriptLibraryIndex.java
✅ Files skipped from review due to trivial changes (3)
- src/main/java/com/github/_1c_syntax/bsl/languageserver/context/symbol/KeywordSymbol.java
- src/main/java/com/github/_1c_syntax/bsl/languageserver/providers/HoverProvider.java
- src/main/java/com/github/_1c_syntax/bsl/languageserver/hover/KeywordSymbolMarkupContentBuilder.java
|



Зачем
references ↔ types— последний реальный кросс-доменный цикл ядра. Естественное направление —referencesснизу (type-agnostic разрешение имён),typesсверху (вывод типов опирается наразрешение имён). Значит оставляем
types → references, убираемreferences → typesцеликом.Этих рёбер было 6: пять давали три «type-aware» finder'а, шестое —
ReferenceIndexFiller,которому нужно было сматчить имя OneScript-класса/модуля в его .os-документ.
Что сделано
1. Перенос type-aware finder'ов (5 рёбер).
KeywordReferenceFinder,NewExpressionReferenceFinder,PlatformMemberReferenceFinderрезолвят ссылки, консультируясь ссистемой типов (
TypeService,GlobalScopeProvider, символы типов) — это адаптеры портаReferenceFinder, а не ядро разрешения имён. Порт и чистые finder'ы остались вreferences, этитри переехали в
types.references, к своим зависимостям. Они по-прежнему реализуютreferences.ReferenceFinderи собираютсяReferenceResolver'ом черезList(Spring, независимо от пакета).
2. Унификация OScript-резолва по mdoRef (6-е ребро). Раньше BSL-ссылки резолвились по
логическому mdoRef (
MdoRefBuilder/findCommonModuleизcontext) черезServerContext.getDocument(mdoRef, moduleType), а OScript был исключением — ключевался по URI,потому что у .os-доков библиотек нет объекта метаданных, а значит и логического mdoRef. Привёл
OScript к BSL — теперь у library-.os-документа
mdoRef= его каноничное lib-имя:OScriptLibraryIndexприregisterEntryдоaddDocumentсеет привязкуURI → каноничное имявServerContext(registerOScriptLibraryName);MdoRefBuilderдля .os-файла безMD-объекта берёт mdoRef из этой привязки (а не из URI). Так документ попадает в
documentsByMDORefпод своим же mdoRef — механизмомaddMdoRefByUri, единообразно с BSL.Мультиидентичность (один файл — несколько lib-имён/ролей) схлопывается в одну стабильную
идентичность документа (первое имя выигрывает, как и
ModuleTypeвOScriptModuleTypeResolver);под каждый
ModuleType-роль документ доступен через тот же mdoRef.ServerContextдержит каталог lib-сущностей (имя → (ModuleType, DocumentContext),регистронезависимый) для резолва имени класса/модуля в документ — параллельно
findCommonModule.findLibraryClass/findLibraryModuleтеперь возвращаютDocumentContext(а не строку-имя):вызывающему нужен именно документ (конструктор, символы), а ключ индекса он берёт из
doc.getMdoRef().ReferenceIndexFillerберёт документ черезfindLibrary…, пишетmdoRef = doc.getMdoRef()исинтаксический
ModuleType; лишний round-tripgetDocument(mdoRef, moduleType)и хелперlibraryClassConstructorубраны. Зависимостьreferences → typesиз филлера ушла.3. Починка висячих javadoc-
@link. Три ссылки наKeywordReferenceFinderвcontext.symbol/hover/providersостались указывать на старый пакет после переезда финдера вtypes.references(шаг 1) — обновлены на новый FQN (из-за них CIcheckпадал наjavadoc).Граф
references → types= 0 — цикл разорван,referencesстал нижним слоем. Из реальных цикловядра не осталось ни одного (после
configuration↔contextв #4229). МодельArchitectureTestобновлена:
Referencesбольше не обращается кTypes, осталось толькоtypes → references.Инварианты (по ревью-замечаниям)
contextне зависит отtypes: каталог/привязки наServerContextиспользуют толькоконтекст-безопасные типы (
String/URI/DocumentContext/внешнийbsl.types.ModuleType) —цикла
context↔typesне возникает.findLibraryClass/Module— в том же доменеcontext, что иfindCommonModule(не переведён на API типов).addMdoRefByUri/mdoRefs) концептуально не тронут — .os теперь простоидёт по нему же, получив каноничный mdoRef.
Проверки
Локально зелёные: полный
./gradlew test—BUILD SUCCESSFUL, 0 падений (включаяArchitectureTestсlayer_dependencies_are_respected/acyclic_domains_stay_free_of_cyclesи всеOScript-тесты резолюции/определения/hover/completion/signature), плюс
spotlessCheckиjavadoc.Дальше (отдельно)
Консолидация
OScriptLibraryIndex↔GlobalScopeProvider(оба держатимя/тип ↔ URIвtypes) —отложена в отдельный шаг.
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes