Обновление версии mdclasses и восстановление работы диагностики #3218
Conversation
WalkthroughThe changes encompass updating a dependency version in the build configuration and modifying Java code to accommodate an updated API. Specifically, the Changes
Assessment against linked issues
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChat with CodeRabbit Bot (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (3)
- build.gradle.kts (1 hunks)
- src/main/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/WrongDataPathForFormElementsDiagnostic.java (4 hunks)
- src/test/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/WrongDataPathForFormElementsDiagnosticTest.java (5 hunks)
Files skipped from review due to trivial changes (1)
- build.gradle.kts
Additional comments: 7
src/main/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/WrongDataPathForFormElementsDiagnostic.java (4)
- 32-32: The import statement for
FormItemhas been updated to reflect the new package structure. Ensure that all references toFormItemin the codebase are updated accordingly.Verification successful
The search results confirm that the updated import statement for
FormItemis only present in theWrongDataPathForFormElementsDiagnostic.javafile. This suggests that the change in the package structure forFormItemis localized to this file, and no other files in the codebase are affected by this change.* 66-67: The method `wrongDataPath` has been updated to use `getSegments()` which aligns with the changes in the MDClasses library. Confirm that `getSegments()` is the correct method in the updated API and that it is used properly here.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that all instances of FormItem are imported from the new package. rg --type java 'import com.github._1c_syntax.bsl.mdo.storage.form.FormItem'Length of output: 248
86-87: The method
checkAllFormsWithoutModulesnow usesgetPlainChildren()instead of a stream-based approach. This change should be verified to ensure it correctly retrieves form items as intended by the updated MDClasses API.103-107: The
checkFormmethod has been updated to usegetPlainItems()instead ofgetPlainChildren(). This change should be verified to ensure that it aligns with the updated MDClasses API and that the method is used correctly to access form items.src/test/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/WrongDataPathForFormElementsDiagnosticTest.java (3)
- 34-34: The import statement for
Collectionshas been added. Verify that this import is used in the test code, and there are no unused imports.Verification successful
The import of
java.util.Collectionsis used in the test code forWrongDataPathForFormElementsDiagnosticTest.javato return an empty list from a mockedFormobject. This confirms that the import is necessary and is being utilized as expected.* 66-66: The mocking behavior for `context.getConfiguration()` has been added. Ensure that the mocking is necessary and correctly implemented to reflect the behavior of the updated MDClasses API.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that Collections is used in the test code. rg --type java 'Collections' -- 'src/test/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/WrongDataPathForFormElementsDiagnosticTest.java'Length of output: 256
Verification successful
The shell script executed to verify the mocking of
context.getConfiguration()in theWrongDataPathForFormElementsDiagnosticTest.javafile did not produce any output. This could mean that the specific line of code does not exist in the file, or there might have been an issue with the search command.To ensure we have accurate information, I will generate a new shell script to list the contents of the
WrongDataPathForFormElementsDiagnosticTest.javafile to confirm the presence of the mocking statement and to understand the context in which it is used.
The output from the
catcommand shows the contents of theWrongDataPathForFormElementsDiagnosticTest.javafile. Within thetestNoFormModulemethod, the mocking statementwhen(context.getConfiguration()).thenReturn(configuration);is indeed present. This confirms that the mocking behavior is part of the test setup and is used to configure the context with a specific configuration before running the test.Given this information, the mocking behavior appears to be correctly implemented in the context of the test. It is used to set up the test environment to simulate the behavior of the
contextobject as it would occur with the updated MDClasses API.* 101-110: The `fillConfigChildrenByFormsWithoutModule` method has been updated to use `getPlainChildren()` and mock the `getModules()` method. Verify that these changes are correct and align with the updated MDClasses API.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that the mocking of context.getConfiguration() is necessary and correctly implemented. rg --type java 'when(context.getConfiguration())' -- 'src/test/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/WrongDataPathForFormElementsDiagnosticTest.java'Length of output: 169
Script:
#!/bin/bash # List the contents of WrongDataPathForFormElementsDiagnosticTest.java to confirm the presence of the mocking statement. cat 'src/test/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/WrongDataPathForFormElementsDiagnosticTest.java'Length of output: 4640
Verification successful
The search results confirm the usage of
getPlainChildren()andgetModules()methods in various parts of the codebase, including theWrongDataPathForFormElementsDiagnostic.javaand its corresponding test fileWrongDataPathForFormElementsDiagnosticTest.java. This indicates that the methods are indeed part of the codebase and are being used as described in the PR comment.Given this information, the changes made in the
WrongDataPathForFormElementsDiagnosticTest.javafile, which involve usinggetPlainChildren()to filter and mockFormobjects and then mocking thegetModules()method to return an empty list, are consistent with the usage patterns found in the codebase. This suggests that the changes align with the updated MDClasses API and are implemented correctly in the context of the test.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that getPlainChildren() and the mocking of getModules() are correctly implemented. ast-grep --lang java --pattern $'CF { $$$ getPlainChildren() { $$$ } $$$ }'Length of output: 435
Script:
#!/bin/bash # Search for the 'getPlainChildren()' method in the Java files to verify its usage. ast-grep --lang java --pattern $'class $_ { $$$ getPlainChildren() { $$$ } $$$ }'Length of output: 96
Script:
#!/bin/bash # Search for the usage of 'getPlainChildren()' and 'getModules()' in the Java files. rg "getPlainChildren\(\)" -t java rg "getModules\(\)" -t javaLength of output: 3026
Qodana Community for JVM17 new problems were found
💡 Qodana analysis was run in the pull request mode: only the changed files were checked Contact Qodana teamContact us at qodana-support@jetbrains.com
|
|
Описание
Связанные задачи
Closes #3215
Чеклист
Общие
gradlew precommit)Для диагностик
Дополнительно
Summary by CodeRabbit
Refactor
Bug Fixes