Repository navigation
SONARJAVA-7297 Decouple Problems and Warnings from Eclipse JDT core specifics - #6479
Conversation
hashicorp-vault-sonar-prod
Bot
changed the title
![gitar-bot[bot]](https://avatars.githubusercontent.com/in/827041?s=60&v=4){kind=small}
7c815a7 to
a4eb5fe
Compare
|
/pvf |
|
📊 Performance Validation complete Projects with unexpected PVF results:
|
a4eb5fe to
a76602c
Compare
a76602c to
fff74ac
Compare
rombirli
left a comment
rombirli
left a comment
There was a problem hiding this comment.
LGTM, few questions regarding Beta annoration and key record
| return context.config(); | ||
| } | ||
|
|
||
| private record ProblemKey(ProblemKind type, String message) {} |
There was a problem hiding this comment.
This tuple type/message doesn't seem unique to me, for example there can be twice the same unused import in 2 different files or even in the same file. Should we assign UUID to problems or location range to ensure uniqueness
There was a problem hiding this comment.
I'm asking because "Key" seems to mean they must be unique (and I see they are used as hashmaps keys)
There was a problem hiding this comment.
This is expected here. ProblemKey is used as the key type in SonarComponents.problemsToFilePaths, which maps problem kinds the list of files where they occur. Two different problems occurring in different files but with the same kind and message should thus share the same key, so that we can retrieve the list of files where this problem is observed.
There was a problem hiding this comment.
Understoood, NIT : ProblemGroupKey or ProblemBucketKey would be clearer to me
4a7a124 to
c0b083d
Compare
Code Review ✅ Approved 2 closed / 2 findings🟡 Medium risk · Refactoring Java diagnostics and parser classification could change which compiler warnings become issues, potentially omitting or misattributing findings. Decouples problems and warnings from Eclipse JDT core types by introducing ✅ 2 closed✅ Quality: End-position change in convert() is untested; test name says 'point'
✅ Quality: Test stubs a second getID() value that convert() never reads
Verification Rules 2/2 met Repos 4 inspected · PRs 1 inspectedFunctional validation No results Rules 2 passed 1 not applicable
Broader impact Repos 4 inspected PRs 1 inspectedCross-repo 4 repositories inspected 0 open impacts
Cross-PR 1 PR inspected 0 open impacts
Auto-approval Not enabledFor more verification details, comment OptionsAuto-apply is off → Gitar will not commit updates to this branch. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Gitar |
|
/pvf |
|
|
📊 Performance Validation complete Projects with unexpected PVF results:
|
|
📊 Performance Validation complete |
Summary by Gitar
Problem,Warning, andProblemKindinterfaces underorg.sonar.plugins.java.api.diagnostics, decoupling problems from Eclipse JDT typessemanticProblems(),supportedWarningKinds(), andwarnings(ProblemKind)onCompilationUnitTreeUselessImportCheck,RedundantTypeCastCheck,SelfAssignmentCheck, andUnreachableCatchCheckto use the new API instead ofJWarning/JProblem.TypeJProblem.Typeenum withProblemKindmapping from ECJ problem IDs, and moved undefined-type collection inSonarComponentsto aProblemKeyrecordUselessImportCheckto derive import names from the syntax tree instead of parsing ECJ messagesJWarning.MapperJProblemconstructorSymbolandTypeinstead of ECJ bindingsThis will update automatically on new commits.