Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/main/java/com/github/_1c_syntax/bsl/languageserver/inlayhints/VariableTypeInlayHintSupplier.java (1)

145-147: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Guard typeName before resolution to keep malformed data a no-op.

resolve(...) trusts data.getTypeName() unconditionally. If deserialization yields null/blank, this path can fail or produce invalid tooltip state; unresolved hint should be returned unchanged in that case.

Suggested fix

   public InlayHint resolve(
     DocumentContext documentContext,
     InlayHint unresolved,
     VariableTypeInlayHintData data
   ) {
-    var typeRef = typeService.resolve(data.getTypeName(), documentContext.getFileType())
-      .orElse(new TypeRef(TypeRef.UNKNOWN.kind(), data.getTypeName()));
+    var typeName = data.getTypeName();
+    if (typeName == null || typeName.isBlank()) {
+      return unresolved;
+    }
+    var typeRef = typeService.resolve(typeName, documentContext.getFileType())
+      .orElse(new TypeRef(TypeRef.UNKNOWN.kind(), typeName));

🤖 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/inlayhints/VariableTypeInlayHintSupplier.java`
around lines 145 - 147, Before calling typeService.resolve() in the
VariableTypeInlayHintSupplier class, add a guard check to validate that
data.getTypeName() is not null and not blank. If the type name is null or blank,
return an unresolved TypeRef (such as new TypeRef(TypeRef.UNKNOWN.kind(),
data.getTypeName())) directly as a no-op without calling resolve(), since
malformed or missing type names should not be processed further and should
prevent invalid tooltip state from occurring.

src/main/java/com/github/_1c_syntax/bsl/languageserver/providers/InlayHintProvider.java (1)

116-129: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

extractData can crash inlayHint/resolve on non-JSON data payloads.

jsonMapper.readValue(rawData.toString(), InlayHintData.class) assumes toString() is valid JSON. For map/object round-trips this is often false, and with @SneakyThrows the exception bubbles up through resolve path instead of returning “unresolved as-is”.

Suggested fix

-  `@SneakyThrows`
   public `@Nullable` InlayHintData extractData(InlayHint inlayHint) {
     var rawData = inlayHint.getData();

     if (rawData == null) {
       return null;
     }

     if (rawData instanceof InlayHintData data) {
       return data;
     }

-    return jsonMapper.readValue(rawData.toString(), InlayHintData.class);
+    try {
+      return jsonMapper.convertValue(rawData, InlayHintData.class);
+    } catch (RuntimeException ex) {
+      return null;
+    }
   }

🤖 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/providers/InlayHintProvider.java`
around lines 116 - 129, The extractData method assumes that rawData.toString()
always produces valid JSON when passed to jsonMapper.readValue(), but non-JSON
payloads will cause parsing to fail. With `@SneakyThrows`, this exception
propagates up and crashes the inlayHint/resolve operation. Wrap the
jsonMapper.readValue(rawData.toString(), InlayHintData.class) call in a
try-catch block to handle JsonProcessingException or similar parsing failures,
returning null when the conversion fails instead of allowing the exception to
bubble up. This allows the resolve operation to gracefully handle unresolvable
data payloads.

src/main/java/com/github/_1c_syntax/bsl/languageserver/databind/JsonMapperConfiguration.java (1)

56-65: ⚡ Quick win

Replace side-effect collect(...) calls with direct accumulation.

These collect(Collectors.toCollection(() -> namedTypes)) calls are used only for side effects and trigger PMD UselessPureMethodCall. Using forEach(namedTypes::add) is clearer and avoids the warning.

Suggested refactor

-    codeLensResolvers.stream()
-      .map(JsonMapperConfiguration::toNamedType)
-      .collect(Collectors.toCollection(() -> namedTypes));
-    commandSuppliers.stream()
-      .map(JsonMapperConfiguration::toNamedType)
-      .collect(Collectors.toCollection(() -> namedTypes));
-    inlayHintSuppliers.stream()
-      .filter(inlayHintSupplier -> inlayHintSupplier.getInlayHintDataClass() != null)
-      .map(JsonMapperConfiguration::toNamedType)
-      .collect(Collectors.toCollection(() -> namedTypes));
+    codeLensResolvers.stream()
+      .map(JsonMapperConfiguration::toNamedType)
+      .forEach(namedTypes::add);
+    commandSuppliers.stream()
+      .map(JsonMapperConfiguration::toNamedType)
+      .forEach(namedTypes::add);
+    inlayHintSuppliers.stream()
+      .filter(inlayHintSupplier -> inlayHintSupplier.getInlayHintDataClass() != null)
+      .map(JsonMapperConfiguration::toNamedType)
+      .forEach(namedTypes::add);

🤖 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/databind/JsonMapperConfiguration.java`
around lines 56 - 65, The code uses collect(Collectors.toCollection(() ->
namedTypes)) calls purely for side effects to add items to the namedTypes
collection, which triggers a PMD UselessPureMethodCall warning. Replace all
three of these collect calls (one for codeLensResolvers stream, one for
commandSuppliers stream, and one for inlayHintSuppliers stream) with
forEach(namedTypes::add) instead, which is clearer in intent and explicitly
designed for side effects. This change applies to all three stream chains in the
diff.

Source: Linters/SAST tools