src/main/java/com/github/_1c_syntax/bsl/languageserver/types/registry/BuiltinOScriptPlatformTypesProvider.java (1)

37-40: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Update the class JavaDoc to match the new FileType contract.

This comment still says language gating is handled elsewhere, but this provider now explicitly declares its visibility through getFileType() returning FileType.OS. Leaving the old wording behind is misleading during this migration.

As per coding guidelines, "Write JavaDoc for public APIs, include comments for complex logic, and keep documentation up to date with code changes."

🤖 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/registry/BuiltinOScriptPlatformTypesProvider.java`
around lines 37 - 40, Update the class JavaDoc for
BuiltinOScriptPlatformTypesProvider to reflect the new FileType contract: remove
the statement that language gating is handled elsewhere and explicitly document
that this provider declares its visibility by returning FileType.OS from
getFileType(), describe the effect/intent (only OS files), and note that it
still reuses the builtin-platform-types.json loader for resource behavior; keep
the doc concise and aligned with the public API contract.

Source: Coding guidelines

src/main/java/com/github/_1c_syntax/bsl/languageserver/types/registry/KeywordMetadataBuilder.java (1)

40-44: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Remove the obsolete “+ scope” wording from the builder JavaDoc.

The builder no longer tracks or exports per-keyword scope, so this description is now inaccurate. It should describe only the keyword list, snippets, and descriptions that KeywordMetadata still contains.

As per coding guidelines, "Write JavaDoc for public APIs, include comments for complex logic, and keep documentation up to date with code changes."

🤖 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/registry/KeywordMetadataBuilder.java`
around lines 40 - 44, Update the JavaDoc on KeywordMetadataBuilder to remove the
obsolete "+ scope" phrase and make the description match current behavior: state
that it accumulates parsing of builtin-keywords.json into KeywordMetadata,
producing a flat list of names, snippets and descriptions (including
descriptionByParent), and that each name is added in both ru-canonical and
en-alias lower-cased. Edit the class-level comment in KeywordMetadataBuilder
(referencing KeywordMetadata) to remove any mention of per-keyword scope and
ensure the wording accurately reflects only the keyword list, snippets, and
descriptions exported.

Source: Coding guidelines

src/main/java/com/github/_1c_syntax/bsl/languageserver/types/registry/TypeRegistry.java (3)

999-1005: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Drop constructor state when unregistering a user type.

unregisterUserType clears member sources, but it leaves constructors and constructorSources behind. For .os classes this leaks the old DocumentContext suppliers and duplicates constructor signatures when the same class name is registered again later.

Suggested fix

   public void unregisterUserType(String qualifiedName) {
     var ref = intern(TypeKind.USER, qualifiedName);
     types.remove(ref);
     memberSources.remove(ref);
+    constructors.remove(ref);
+    constructorSources.remove(ref);
     membersEpoch.incrementAndGet();
     visibleTypes.values().forEach(typed -> typed.remove(ref));
     aliasIndex.remove(qualifiedName.toLowerCase(Locale.ROOT));
   }

🤖 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/registry/TypeRegistry.java`
around lines 999 - 1005, unregisterUserType currently removes types and
memberSources but leaves constructor-related state, causing leaks and duplicate
constructor signatures; update unregisterUserType (the method that does
intern(TypeKind.USER, qualifiedName) and removes from types, memberSources,
visibleTypes and aliasIndex) to also remove any entries keyed by the same ref
from constructors and constructorSources and then update the constructorsEpoch
(or equivalent epoch/version used for constructor change notifications) to
reflect the mutation so suppliers are dropped and subsequent re-registration
won't duplicate constructors.

---

499-513: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Preserve additive visibility when a specialization already exists.

When specializedName is already present, this path reuses the existing TypeRef but skips registerFileType(...). That leaves visibleTypes unchanged, so the second language variant stays unresolved by resolve(name, fileType) even though you just registered scoped members for it.

Suggested fix

     if (existing == null) {
       // Регистрируем как полноценный тип того же kind, что и generic, чтобы
       // инференсер (резолвящий типы по имени через aliasIndex / по паре
       // (kind, name)) находил тот же TypeRef и member-source'ы доходили
       // до getMembers.
       types.put(specializedRef, hydrate(specializedRef));
       addAlias(specializedName, specializedRef);
-      registerFileType(specializedRef, fileType);
     }
+    registerFileType(specializedRef, fileType);
     registerSpecialization(specializedRef, genericRef, bindings, fileType);

🤖 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/registry/TypeRegistry.java`
around lines 499 - 513, The code reuses an existing TypeRef from
resolve(specializedName) but does not call registerFileType(...) for that
existing ref, so visibleTypes isn't updated and resolve(name, fileType) can fail
for the second variant; update the logic in the block around resolve/intern so
that when existing != null you still call registerFileType(existing, fileType)
(or always call registerFileType(specializedRef, fileType) after computing
specializedRef) before registerSpecialization, ensuring
types.put/hydrate/addAlias remain unchanged but visibility is preserved for the
file-scoped resolution.

---

555-572: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Thread fileType into generic-derived members.

Both specialization and member expansion currently read the source generic via unfiltered getMembers(genericRef). That reintroduces the BSL/OS mixing this PR is trying to remove: a BSL-only derived type can materialize OS members, and vice versa, whenever the generic exists in both slices.

Suggested direction

     MemberSource source = () -> {
-      var raw = getMembers(genericRef);
+      var raw = getMembers(genericRef, fileType);
       if (raw.isEmpty()) {
         return List.of();
       }
       var result = new ArrayList<MemberDescriptor>(raw.size());

     MemberSource source = () -> {
-      var materialized = expandGenericMembers(genericRef, safeTypeBindings, safeExpansions);
+      var materialized = expandGenericMembers(genericRef, safeTypeBindings, safeExpansions, fileType);

-  private List<MemberDescriptor> expandGenericMembers(TypeRef genericRef,
-                                                      Map<String, String> typeBindings,
-                                                      Map<String, List<String>> memberExpansions) {
-    var raw = getMembers(genericRef);
+  private List<MemberDescriptor> expandGenericMembers(TypeRef genericRef,
+                                                      Map<String, String> typeBindings,
+                                                      Map<String, List<String>> memberExpansions,
+                                                      FileType fileType) {
+    var raw = getMembers(genericRef, fileType);

Also applies to: 611-620, 662-676

🤖 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/registry/TypeRegistry.java`
around lines 555 - 572, The member expansion uses getMembers(genericRef) without
respecting the fileType, allowing OS/BSL members from the generic slice to leak
into specialized types; update the MemberSource logic used when creating
specializedRef (and the analogous locations ~611-620 and ~662-676) to only
iterate members filtered by the same fileType as the derived type—i.e., call the
fileType-aware member lookup (or add a fileType parameter to getMembers) instead
of plain getMembers(genericRef), then continue to specialize and index only
those members so member.specialize(safeBindings) and
memberMetadataIndex.index(specializedRef, specialized) operate on the correctly
filtered set before registerMemberSource(specializedRef, source, fileType).

src/main/java/com/github/_1c_syntax/bsl/languageserver/types/registry/GlobalScopeProvider.java (2)

319-320: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Keep library handling scoped to the OS slice.

These paths still treat library names as global across both languages. In findGlobal, any OS library name collision suppresses the BSL symbol on the same name. In unregisterLibrarySymbol, findSymbol(name) returns the first slice match, so removing an OS library entry can unregister the BSL symbol instead.

Suggested direction

-    if (oScriptLibraryIndex != null && oScriptLibraryIndex.findByName(lc).isPresent()) {
-      return fileType == FileType.OS ? sym : Optional.empty();
-    }

   private void unregisterLibrarySymbol(String name) {
     if (name == null || name.isBlank()) {
       return;
     }
-    globalSymbolScope.findSymbol(name).ifPresent(globalSymbolScope::unregister);
+    globalSymbolScope.findEntry(name, FileType.OS)
+      .map(GlobalSymbolScope.Entry::symbol)
+      .ifPresent(globalSymbolScope::unregister);
   }

Also applies to: 731-735

🤖 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/registry/GlobalScopeProvider.java`
around lines 319 - 320, The library lookup and removal logic is incorrectly
treating OS libraries as global across slices; update the checks in findGlobal
and unregisterLibrarySymbol so library name resolution and unregistration only
consider the OS slice: in findGlobal, only consult
oScriptLibraryIndex.findByName(lc) when the current fileType equals FileType.OS
(keep the existing return sym only for OS and otherwise skip library hits), and
in unregisterLibrarySymbol avoid using the generic findSymbol(name) that returns
the first slice match—use a slice-aware lookup or filter by FileType.OS (or
explicitly target the OS slice index) so removing an OS library entry cannot
unregister a BSL symbol with the same name. Ensure references to
oScriptLibraryIndex, findGlobal, unregisterLibrarySymbol, findSymbol(name), and
FileType.OS are updated accordingly.

---

611-628: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

getGlobalContexts(FileType) is no longer filtering builtin/platform entries correctly.

matchesGlobalScope only consults globalContextNames, but that index is populated only by dynamic registerGlobalProperty(...) calls. Builtin platform globals, enums, and library modules are therefore treated as “not registered anywhere” and leak into both getGlobalContexts(fileType) and getGlobalContextNames(fileType).

Suggested direction

   public List<SyntheticSymbol> getGlobalContexts(FileType fileType) {
     return getGlobalContexts().stream()
-      .filter(s -> matchesGlobalScope(s.getName(), fileType))
+      .filter(s -> findGlobalEntry(s.getName(), fileType).isPresent())
       .toList();
   }

Also applies to: 652-661

🤖 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/registry/GlobalScopeProvider.java`
around lines 611 - 628, matchesGlobalScope currently checks only the dynamic
index (globalContextNames populated by registerGlobalProperty), so
builtin/platform globals and library-module symbols are missed; update
matchesGlobalScope to also consult the canonical names of built-in globals
(e.g., the canonical names from the existing builtins/enums/library-module
registry) or simply derive the allowed names from getGlobalContexts() instead of
only the globalContextNames field; ensure getGlobalContexts(FileType) and
getGlobalContextNames(FileType) then correctly filter by calling the updated
matchesGlobalScope so builtin/platform entries are excluded when they don't
match the fileType.

src/main/java/com/github/_1c_syntax/bsl/languageserver/types/registry/TypeRegistry.java (2)

556-557: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Keep derived members scoped to the caller's FileType.

These paths still call getMembers(genericRef) without fileType, and that overload explicitly disables scoping. Once a generic template has different BSL/OS member sources, specialization and member expansion merge them back together, so derived types can leak wrong-language members into hover/completion again.

Proposed fix

   public void registerSpecialization(TypeRef specializedRef, TypeRef genericRef,
                                      Map<String, String> bindings, FileType fileType) {
@@
     registerSpecializedDisplayName(specializedRef, genericRef, safeBindings);
     MemberSource source = () -> {
-      var raw = getMembers(genericRef);
+      var raw = getMembers(genericRef, fileType);
       if (raw.isEmpty()) {
         return List.of();
       }
@@
   private List<MemberDescriptor> expandGenericMembers(TypeRef genericRef,
+                                                      FileType fileType,
                                                       Map<String, String> typeBindings,
                                                       Map<String, List<String>> memberExpansions) {
-    var raw = getMembers(genericRef);
+    var raw = getMembers(genericRef, fileType);
     if (raw.isEmpty()) {
       return List.of();
     }

     MemberSource source = () -> {
-      var materialized = expandGenericMembers(genericRef, safeTypeBindings, safeExpansions);
+      var materialized = expandGenericMembers(genericRef, fileType, safeTypeBindings, safeExpansions);
       // Индексируем как делает registerSpecialization: read-only/версионные
       // members проверяются через memberMetadataIndex.
       for (var member : materialized) {

Also applies to: 663-666

🤖 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/registry/TypeRegistry.java`
around lines 556 - 557, The MemberSource lambda currently calls
getMembers(genericRef) which uses the unscoped overload and thus can pull
members from the wrong language; update the MemberSource implementations to call
the file-scoped overload getMembers(genericRef, fileType) so derived/specialized
types inherit members limited to the caller's FileType; apply the same change to
the other occurrence(s) around the MemberSource creation (the similar block at
the later occurrence referenced in the review) to ensure derived members never
leak wrong-language members into hover/completion.

---

500-513: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Preserve additive visibility on repeated specialization registration.

Line 511 only records fileType when the specialized ref is created. If the same specialized name is later registered for the other language, resolve(name, otherFileType) still filters it out because visibleTypes was never updated for that second registration.

Proposed fix

     if (existing == null) {
       // Регистрируем как полноценный тип того же kind, что и generic, чтобы
       // инференсер (резолвящий типы по имени через aliasIndex / по паре
       // (kind, name)) находил тот же TypeRef и member-source'ы доходили
       // до getMembers.
       types.put(specializedRef, hydrate(specializedRef));
       addAlias(specializedName, specializedRef);
-      registerFileType(specializedRef, fileType);
     }
+    registerFileType(specializedRef, fileType);
     registerSpecialization(specializedRef, genericRef, bindings, fileType);
     return specializedRef;

🤖 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/registry/TypeRegistry.java`
around lines 500 - 513, The code only calls registerFileType(specializedRef,
fileType) when the specialized TypeRef is newly created, so repeated
registrations from another fileType miss updating visibleTypes; change the flow
so that registerFileType(specializedRef, fileType) is invoked for every
registration (whether existing != null or created), e.g., move or duplicate the
call so that after resolving/interning specializedRef you always call
registerFileType(specializedRef, fileType) before registerSpecialization(...),
keeping types.put/addAlias only for the new-creation branch and leaving resolve,
intern, types.put, addAlias and registerSpecialization behavior unchanged.

src/main/java/com/github/_1c_syntax/bsl/languageserver/types/registry/TypeRegistry.java (2)

942-949: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Clean up constructor registrations when a user type is removed.

unregisterUserType(...) drops types and memberSources, but any constructorSources already registered for the same interned TypeRef remain. Re-indexing a deleted/re-added .os class with the same name will then reuse stale suppliers and can duplicate or surface outdated constructor signatures.

Suggested fix

   public void unregisterUserType(String qualifiedName) {
     var ref = intern(TypeKind.USER, qualifiedName);
     types.remove(ref);
     memberSources.values().forEach(byRef -> byRef.remove(ref));
+    constructors.values().forEach(byRef -> byRef.remove(ref));
+    constructorSources.values().forEach(byRef -> byRef.remove(ref));
     membersEpoch.incrementAndGet();
     visibleTypes.values().forEach(typed -> typed.remove(ref));
     aliasIndex.remove(qualifiedName.toLowerCase(Locale.ROOT));
   }

🤖 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/registry/TypeRegistry.java`
around lines 942 - 949, unregisterUserType currently removes the type from
types, memberSources and visibleTypes but leaves any entries in
constructorSources, causing stale constructor suppliers to be reused; update
unregisterUserType to also remove the interned TypeRef (ref) from
constructorSources (and any nested collections / maps that store constructors)
and bump the constructors epoch/counter if one exists (e.g., constructorsEpoch)
so re-indexing a deleted/re-added user type cannot reuse stale constructor
suppliers or duplicate signatures.

---

467-480: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Register FileType visibility even when the specialization already exists.

If specializedName was first created from the other language pass, this path reuses the existing TypeRef but skips registerFileType(...). The new member source is added for fileType, yet resolve(name, fileType) still filters that type out via isVisibleIn(...), so shared BSL/OS specializations stay unreachable in the second language.

Suggested fix

     if (existing == null) {
       // Регистрируем как полноценный тип того же kind, что и generic, чтобы
       // инференсер (резолвящий типы по имени через aliasIndex / по паре
       // (kind, name)) находил тот же TypeRef и member-source'ы доходили
       // до getMembers.
       types.put(specializedRef, hydrate(specializedRef));
       addAlias(specializedName, specializedRef);
-      registerFileType(specializedRef, fileType);
     }
+    registerFileType(specializedRef, fileType);
     registerSpecialization(specializedRef, genericRef, bindings, fileType);

🤖 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/registry/TypeRegistry.java`
around lines 467 - 480, The code currently skips
registerFileType(specializedRef, fileType) when an existing TypeRef is reused,
causing visibility filtering to hide cross-language specializations; always
register the file visibility for the specialized TypeRef (call
registerFileType(specializedRef, fileType)) even when resolve(specializedName)
returns an existing entry. Concretely, ensure registerFileType is invoked for
specializedRef regardless of the existing==null branch (i.e., move or add
registerFileType(specializedRef, fileType) so it runs before
registerSpecialization), keeping the rest of the existing/intern, types.put,
addAlias, hydrate, and registerSpecialization logic unchanged.

src/main/java/com/github/_1c_syntax/bsl/languageserver/types/registry/TypeRegistry.java (1)

513-537: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Register specialized refs in visibleTypes on every specialization call.

This overload adds a fileType-scoped member source, but it never calls registerFileType(specializedRef, fileType). If the same specialization is reused in a second language, resolve(name, secondFileType) still filters it out via isVisibleIn, so lookup-driven features keep missing it even though the members were registered for that fileType. A single registerFileType(specializedRef, fileType) here fixes both overload paths.

Suggested fix

 public void registerSpecialization(TypeRef specializedRef, TypeRef genericRef,
                                    Map<String, String> bindings, FileType fileType) {
   if (specializedRef == null || genericRef == null) {
     return;
   }
+  registerFileType(specializedRef, fileType);
   var safeBindings = Map.copyOf(bindings);
   registerSpecializedDisplayName(specializedRef, genericRef, safeBindings);
   MemberSource source = () -> {

🤖 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/registry/TypeRegistry.java`
around lines 513 - 537, The registerSpecialization(TypeRef specializedRef,
TypeRef genericRef, Map<String,String> bindings, FileType fileType) method
registers a fileType-scoped member source but never marks the specializedRef as
visible for that file type; call registerFileType(specializedRef, fileType) (the
same visibility registration used by the other overload) before or after
registerMemberSource so isVisibleIn checks will include this specializedRef
during resolve(name, fileType) lookups and avoid missing members; update the
method to invoke registerFileType for specializedRef and fileType.