You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: resolve handle leak in image descriptor handling [IDE-1421] (#323)
* fix: resolve handle leak in image descriptor handling [IDE-1421]
- Replace getImageDescriptorFromImage() with direct workbench registry access
- Fix handle leak caused by getImageData() creating unreleased GC handles
- Add comprehensive tests for TreeLabelProvider image caching and disposal
- Improve thread safety in TreeLabelProvider with proper synchronization
- Add tests to verify no handle leaks in BaseTreeNode
The fix eliminates the SWTError: No more handles error by avoiding the creation
of GC handles entirely and getting ImageDescriptors directly from Eclipse's
workbench registry instead of converting from Images.
* chore: make linter happy
* fix: low-level java error when trying to init display for tests
* fix: delete test for label provider, as mocking the Display is not working on linux
- always be concise, direct and don't try to appease me.
4
+
- use .github/CONTRIBUTING.md and the links in there to find standards and contributing guide lines
5
+
- DOUBLE CHECK THAT YOUR CHANGES ARE REALLY NEEDED. ALWAYS STICK TO THE GIVEN GOAL, NOT MORE.
6
+
- I repeat: don't optimize, don't refactor if not needed.
7
+
- Adhere to the rules, fix linting & test issues that are newly introduced.
8
+
- the `issueID` is usually specified in the current branch in the format `XXX-XXXX`.
9
+
- always create an implementation plan and save it to the directory under ${issueID}_implementation_plan but never commit it. Get confirmation that the plan is ok.
10
+
11
+
12
+
## how to implement
13
+
- do atomic commits, see committing section for details
14
+
- follow the implementation plan step-by-step. take it as a reference for each step and how to proceed.
15
+
- update current status in the implementation plan (in progress work, finished work, next steps)
16
+
- USE TDD
17
+
- I REPEAT: USE TDD
18
+
- Maintain existing code patterns and conventions
19
+
- use existing mocks, don't write new ones.
20
+
- if you use mocks, use gomock to generate them.
21
+
- don't change code that does not need to be changed. only do the minimum changes.
22
+
- don't comment what is done, instead comment why something is done if the code is not clear
23
+
- always write and update test cases before writing the implementation (Test Driven Development). iterate until they pass.
24
+
- after changing .java files, run `./mvn verify`
25
+
- always verify if fixes worked by running `./mvn verify`
26
+
- this is not a library. if files are not used or needed anymore, delete them instead of deprecating them.
27
+
- if a tool call fails, analyze why it failed and correct your approach. don't prompt the user for help.
28
+
- if you don't know something, read the code instead of assuming it.
29
+
- commenting out code to fix errors is not a solution. instead, fix the error.
30
+
- disabling or removing tests IS NOT ALLOWED. This is not a way to success. This can only be done manually by a human.
31
+
- don't do workarounds
32
+
- ALWAYS create production-ready code. We don't want examples, we want working, production-ready code.
33
+
34
+
## security
35
+
- determine the absolute path of the project directory. you can do that e.g. by executing pwd on the shell within the directory.
36
+
- always use snyk for sca and code scanning. scan with both tools. you need to pass the absolute path of the directory we are scanning.
37
+
- run snyk code tests after each edit. pass the absolute path of the project directory as a parameter
38
+
- run snyk sca tests after updating go.mod and pass the absolute path of the project directory as a parameter.
39
+
- run snyk sca and code test before committing. if not test data, fix issues before committing.
40
+
41
+
## fixing issues
42
+
- fix security issues if they are fixable. take the snyk scan results and the test results as input
43
+
- don't fix test data
44
+
45
+
## committing
46
+
- NEVER NEVER NEVER skip the commit hooks
47
+
- I REPEAT: NEVER USE --no-verify. DO NOT DO IT. NEVER. THIS IS CRITICAL, DO NOT DO IT.
48
+
- run `./mvn verify` before committing and fix the issues
49
+
- update the documentation before committing
50
+
- when asked to commit, always use conventional commit messages (Conventional Commit Style (Subject + Body)). be descriptive in the body. if you find a JIRA issue (XXX-XXXX) in the branch name, use it as a postfix to the subject line in the format [XXX-XXXX]
51
+
- consider all commits in the current branch when committing, to have the context of the current changes.
52
+
53
+
## pushing
54
+
- never push without asking
55
+
- never force push
56
+
- when asked to push, always use 'git push --set-upstream origin $(git_current_branch)' with git_current_branch being the current branch we are on
57
+
- regularly fetch main branch and offer to merge it into git_current_branch
58
+
- after pushing offer to create a PR on github if no pr already exists. analyze the changes by comparing the current branch ($(git_current_branch)) with origin/main, and craft a PR description and title.
59
+
- use the github template in .github/PULL_REQUEST_TEMPLATE.md
60
+
- use github mcp, if not found, use `gh` command line util for pr creation.
61
+
- always create draft prs
62
+
- update the github pr description with the current status `gh` command line util
63
+
64
+
documentation
65
+
- always keep the documentation up-to-date in (./docs)
66
+
- create mermaid syntax for all programming flows and add it to the documentation in ./docs
67
+
- use kroti web service to create images of program flows and add it to the documentation in ./docs
68
+
- document the tested scenarios for all testing stages (unit, integration, e2e) in ./docs
0 commit comments