![]() The indexer has a feature that allows readers of the index to read the index in the middle of write operations. This is done by using a YeildableIndexLock. The YeildableIndexLock's yield method can be called to temporarily give up the write lock. However the assumption in the code was that it would always successfully reaquire the lock after that. However, if the indexing was cancelled the lock would fail to be reaquired. Therefore the code that thinks it owns the lock no longer owns it. In this case the code in PDOMWriter.storeSymbolsInIndex's finally block. Therefore I have added an new exception type to explicitly identify this use case so the original code can differentiate between cases where an exception was thrown where the lock is still held, and cases where the lock is no longer held. Note that instead of a new exception caught like this: ```java } catch (FailedToReAcquireLockException e) { hasLock = false; e.reThrow(); ``` I could have done this: ```java } catch (InterruptedException | OperationCanceledException e) { hasLock = false; throw e; ``` But it is not obvious that nothing else other than the acquire can raise an OperationCanceledException because it is a RuntimeException. By having a new checked exception we can know for sure that in the finally block we have lost our lock. There are no API implications of this change as all the classes and interfaces are internal to CDT. Fixes #128 |
||
---|---|---|
.github/workflows | ||
.mvn | ||
build | ||
cmake | ||
codan | ||
core | ||
cross | ||
debug | ||
doc | ||
dsf | ||
dsf-gdb | ||
FAQ | ||
images | ||
jenkins/pod-templates | ||
jsoncdb | ||
jtag | ||
launch | ||
launchbar | ||
llvm | ||
lsp | ||
memory | ||
native | ||
NewAndNoteworthy | ||
releng | ||
remote | ||
terminal | ||
testsrunner | ||
tools.templates | ||
unittest | ||
util | ||
visualizer | ||
windows | ||
.clang-format | ||
.gitattributes | ||
.gitignore | ||
.project | ||
BUILDING.md | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
Downloads.md | ||
GitHubMigration.md | ||
Jenkinsfile | ||
LICENSE | ||
POLICY.md | ||
pom.xml | ||
README.md | ||
TESTING.md |
Eclipse CDT™ C/C++ Development Tools

The Eclipse CDT™ Project provides a fully functional C and C++ Integrated Development Environment based on the Eclipse platform. Features include: support for project creation and managed build for various toolchains, standard make build, source navigation, various source knowledge tools, such as type hierarchy, call graph, include browser, macro definition browser, code editor with syntax highlighting, folding and hyperlink navigation, source code refactoring and code generation, visual debugging tools, including memory, registers, and disassembly viewers.
Highlights of recent releases and release notes are available in the New & Noteworthy.
See also https://projects.eclipse.org/projects/tools.cdt and https://eclipse.org/cdt

Download
The recommended way to obtain Eclipse CDT is to download it as part of the complete Eclipse IDE for C/C++ Developers or Eclipse IDE for Embedded C/C++ Developers or Eclipse IDE for Scientific Computing from the main Eclipse IDE download site.
Alternatively Eclipse CDT can be installed into an existing Eclipse installation using this p2 URL: https://download.eclipse.org/tools/cdt/releases/latest/
(see how)
Downloads links for older versions are available in Downloads.
Help & Support
The Eclipse CDT (C/C++ Development Tools) User Guide can be found in the Eclipse Help - C/C++ Development User Guide.
The Eclipse forum for C/C++ IDE (CDT) is for users to ask questions on how to use Eclipse CDT. It is monitored by fellow users in the community for support. Stack Overflow also has an eclipse-cdt tag that can be added to questions or searched for prevous similar questions.
The Eclipse CDT Plug-in Developer Guide can also be found in the Eclipse Help - CDT Plug-in Developer Guide.
There is an FAQ covering many commonly asked questions for both user and developers and a Contribution Guide for guidance on editing Eclipse CDT's source and submitting changes.
Reporting issues
Please report issues in the GitHub issue tracker.
Vendor Supplied Eclipse CDT
Did you get your version of Eclipse CDT from a vendor (such as a chip maker)? If so, they generally support their customers. In that case issues and support questions should be directed at the vendor in the first instance.
We encourage all vendors who are extending and redistributing Eclipse CDT to engage with the project and contribute fixes and improvements back to the Eclipse CDT project.
Contributing
Contributions are always welcome!
Please bear in mind that this project is almost entirely developed by volunteers. If you do not provide the implementation yourself (or pay someone to do it for you), the bug might never get fixed. If it is a serious bug, other people than you might care enough to provide a fix.
Add-ons for CDT
There are many third-party addons for CDT to make it more productive.
- cmake4eclipse: This Eclipse plug-in automatically generates build-scripts for the Eclipse CDT managed build system from CMake scripts.
- Sloeber: Eclipse Plugins based on Arduino toolchains or a enhanced Arduino IDE.
- CUTE: C++ unit testing plug-in
- Bracketeer: Auto-comments on closing brackets and highlight of matching/mismatching brackets
- And many more in the Eclipse Marketplace, for example, try the CDT tag
Have a tool that you want listed here? Please open a PR
Code of Conduct
This project follows the Eclipse Community Code of Conduct.
Migration from Gerrit, Bugzilla, Wiki, Eclipse Forums
In the summer of 2022 the Eclipse CDT project migrated from Gerrit, Bugzilla, Wiki, Eclipse Forums to GitHub based solutions. Please see GitHub Migration for more details.