eclipse-cdt/cdt

Eclipse CDT™ C/C++ Development Tools

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.

CDT LSP (LSP based C/C++ Editor)

The Eclipse CDT project also provides an LSP based C/C++ Editor. Please see the CDT LSP repo for more details on that project and the future plans for language server protocol and clangd support in Eclipse CDT.

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.

• CDT LSP: LSP based C/C++ Editor provided by the Eclipse CDT project
• 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.

cdt's Issues

save action for CDT

It could be very useful to have a save action in CDT in order to call external tool or scripts to process saved files.
In our case we need to apply clang-format to our C/C++ code base.
Currently we are using the CppStyle eclipse plugin, but it has the problem that it doesn't work when saving multiple file (save all).
it works only with save single file

Core build launch configurations are not persistent.

I noticed the following with core build cmake and make projects.

Create a Core Build Makefile project. Change Build Output Location to "Build in Project directory".
When I close the project and re-open it, the build settings are back to default. The Build Output Location goes back to "Build configuration in specific directory". Or in case of a Cmake project, the generator goes back from Makefile to Ninja.

When I close the project, exit Eclipse, open Eclipse, open the project, the launch configuration disappeared.

The core build launch configurations are only visible in in the launch bar, not in the Run/Debug Configurations dialogs.
The core build launch configurations are of launch-type "Auto C/C++ Local Application" (org.eclipse.cdt.debug.core.localCoreBuildLaunchConfigType). They are present in the .metadata folder, but they contain no build settings. I think that's why the build information is lost when you close the project.

One way to restore a disappeared launch configuration is to delete the project and recreate a new project op top of the old location. Another way is to exit Eclipse and open Eclipse, leaving the project open. New launch configurations will be created for the projects which don't have one.

I would expect that the core build launch configurations would keep their settings and would not disappear.

OS: Linux
CDT: 10.5

CDT need to provide console/terminal emulator for gdb inferior.

CDT can use PTY to connect the running program, by it provide no way to connect the gdb inferior.

A solution is to use a patched native terminal emulator like mintty(Cygwin and MSYS2/MinGW) or konsole(KDE), to call openpty() instead of forkpty() to allocate a pty, and output the device name of the pty slave, then CDT pass that slave device name(/dev/xxx) to gdb through --tty option.

--tty=TTY Use TTY for input/output by the program being debugged.

This has been realized in UltraGDB(https://github.com/ultragdb/ultragdb).

Eclipse fails to find existing symbols and cannot parse basic C++

Description
When opening a CMake generated eclipse project with a toolchain file that contains all necessary include paths and symbols (they show up in the includes browser as well as in the project settings in include paths and symbols) Eclipse fails to:

• Find included header files that can be found in the includes browser
• Parse basic C++ directives

The build targets are all fine and can be run but the IDE is unusable due to the lack of very basic features.

To Reproduce
Steps to reproduce the behavior:

1. Create a CMake project that uses a toolchain file.
2. Configure the project for eclipse with cmake -G "Eclipse CDT4 - Ninja" --toolchain {toolchain-file} -DCMAKE_BUILD_TYPE=Debug -B ../eclipse_project .
3. Open the project in Eclipse
4. Verify that the include paths to all used libraries and system includes appear in the project settings under "Include paths and symbols"
5. Open a C/C++ file that includes a file from either the system includes or a used library.
6. Eclipse marks all includes as non-found, the entire file is marked red since none of the symbols can be found.

Expected behavior
Eclipse can find the included header files and can resolve existing symbols.

Screenshots

Eclipse marks extern "C" as syntax error

Eclipse marks all #define as syntax error

Eclipse can build but cannot find any header

All include folders are present

There is stdio.h in the include folder

Desktop

• OS: Windows 10 / Arch Linux (reproducible in both systems)
• Eclipse Version: 2022-06 (4.24.0) / Version: 2022-09 (4.25.0) (reproducible in both versions)
• Eclipse C/C++ Development Tools 10.7.1.202208222120

org.eclipse.cdt.ui.tests.text.contentassist2.PlainC_CompletionTests

Even with the fixes in #117 I am still seeing tests in org.eclipse.cdt.ui.tests.text.contentassist2.PlainC_CompletionTests fail too often.

Use of parallel in Jenkinsfile causes deadlock on Jenkins

We are using parallel to run tests + code cleanliness in parallel. But this is causing deadlock on the build machine.

cdt/Jenkinsfile

Line 9 in 2089c1d

parallel {

The reason is that the outer agent request:

cdt/Jenkinsfile

Line 2 in 2089c1d

agent any

allocates an executor, and then that executor tries to allocate 2 additional executors to do the two in parallel parts. However if multiple builds allocate the executor requested at Line 2, then the Eclipse CDT project runs out of executors and all of them are waiting.

CDT needs support for DWARF v5

CDT 11.0.0 fails to parse the native x86_64 ELF executable of the Debug build configuration of a trivial project based on the Hello World ANSI C Project template on Ubuntu 22.04 LTS.

make all
Building file: ../src/hello.c
Invoking: GCC C Compiler
gcc -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/hello.d" -MT"src/hello.o" -o "src/hello.o" "../src/hello.c"
Finished building: ../src/hello.c

Building target: hello
Invoking: GCC C Linker
gcc -o "hello" ./src/hello.o
Finished building target: hello

$ gcc --version
gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0

$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.38

Stack trace:
!ENTRY org.eclipse.ui.navigator 4 0 2022-12-07 19:34:51.954 !MESSAGE An exception occurred invoking extension: org.eclipse.cdt.ui.navigator.content for object hello !STACK 0 java.lang.IllegalArgumentException: newPosition > limit: (2049 > 117) at java.base/java.nio.Buffer.createPositionException(Buffer.java:341) at java.base/java.nio.Buffer.position(Buffer.java:316) at java.base/java.nio.ByteBuffer.position(ByteBuffer.java:1516) at java.base/java.nio.MappedByteBuffer.position(MappedByteBuffer.java:321) at java.base/java.nio.MappedByteBuffer.position(MappedByteBuffer.java:73) at org.eclipse.cdt.utils.debug.dwarf.Dwarf.parseDebugAbbreviation(Dwarf.java:539) at org.eclipse.cdt.utils.debug.dwarf.Dwarf.parseDebugInfo(Dwarf.java:475) at org.eclipse.cdt.utils.debug.dwarf.Dwarf.parse(Dwarf.java:449) at org.eclipse.cdt.utils.debug.dwarf.DwarfReader.getSourceFilesFromDebugInfoSection(DwarfReader.java:564) at org.eclipse.cdt.utils.debug.dwarf.DwarfReader.getSourceFiles(DwarfReader.java:542) at org.eclipse.cdt.internal.core.model.Binary.addSourceFiles(Binary.java:314) at org.eclipse.cdt.internal.core.model.Binary.computeChildren(Binary.java:284) at org.eclipse.cdt.internal.core.model.Binary.buildStructure(Binary.java:270) at org.eclipse.cdt.internal.core.model.Openable.generateInfos(Openable.java:264) at org.eclipse.cdt.internal.core.model.CElement.openWhenClosed(CElement.java:428) at org.eclipse.cdt.internal.core.model.CElement.getElementInfo(CElement.java:306) at org.eclipse.cdt.internal.core.model.CElement.getElementInfo(CElement.java:296) at org.eclipse.cdt.internal.core.model.Parent.getChildren(Parent.java:57) at org.eclipse.cdt.internal.ui.BaseCElementContentProvider.getChildren(BaseCElementContentProvider.java:282) at org.eclipse.cdt.internal.ui.cview.CViewContentProvider.getChildren(CViewContentProvider.java:92) at org.eclipse.cdt.internal.ui.navigator.CNavigatorContentProvider.getChildren(CNavigatorContentProvider.java:233) at org.eclipse.ui.internal.navigator.extensions.SafeDelegateTreeContentProvider.getChildren(SafeDelegateTreeContentProvider.java:98) at org.eclipse.ui.internal.navigator.extensions.SafeDelegateTreeContentProvider.getChildren(SafeDelegateTreeContentProvider.java:241) at org.eclipse.ui.internal.navigator.extensions.SafeDelegateTreeContentProvider.getChildren(SafeDelegateTreeContentProvider.java:96) at org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider$1.run(NavigatorContentServiceContentProvider.java:160) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider.internalGetChildren(NavigatorContentServiceContentProvider.java:146) at org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider.getChildren(NavigatorContentServiceContentProvider.java:132) at org.eclipse.jface.viewers.AbstractTreeViewer.getRawChildren(AbstractTreeViewer.java:1438) at org.eclipse.jface.viewers.TreeViewer.getRawChildren(TreeViewer.java:350) at org.eclipse.jface.viewers.StructuredViewer.getFilteredChildren(StructuredViewer.java:850) at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:638) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:837) at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:611) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:790) at org.eclipse.jface.viewers.AbstractTreeViewer.handleTreeExpand(AbstractTreeViewer.java:1565) at org.eclipse.jface.viewers.TreeViewer.handleTreeExpand(TreeViewer.java:897) at org.eclipse.jface.viewers.AbstractTreeViewer$3.treeExpanded(AbstractTreeViewer.java:1577) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:136) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5855) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1529) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1555) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1538) at org.eclipse.swt.widgets.Tree.gtk_test_expand_row(Tree.java:2633) at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2536) at org.eclipse.swt.widgets.Display.windowProc(Display.java:6169) at org.eclipse.swt.internal.gtk3.GTK3.gtk_main_do_event(Native Method) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1597) at org.eclipse.swt.internal.gtk3.GTK3.gtk_main_iteration_do(Native Method) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4514) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1155) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:643) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:550) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:171) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:402) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:596) at org.eclipse.equinox.launcher.Main.run(Main.java:1467) at org.eclipse.equinox.launcher.Main.main(Main.java:1440)

Debug source lookup logs error after launch has been treminated

In our ARTs, we see this logged from time to time:

org.eclipse.core.runtime.CoreException: Stack data not available
	at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:112)
	at org.eclipse.cdt.dsf.debug.sourcelookup.DsfSourceLookupParticipant.getSourceName(DsfSourceLookupParticipant.java:164)
	at org.eclipse.cdt.dsf.debug.sourcelookup.DsfSourceLookupParticipant.findSourceElements(DsfSourceLookupParticipant.java:83)
	at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector$SourceLookupQuery.run(AbstractSourceLookupDirector.java:138)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector.doSourceLookup(AbstractSourceLookupDirector.java:473)
	at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector.getSourceElement(AbstractSourceLookupDirector.java:714)
	at org.eclipse.cdt.dsf.debug.ui.sourcelookup.DsfSourceDisplayAdapter$LookupJob.performLookup(DsfSourceDisplayAdapter.java:223)
	at org.eclipse.cdt.dsf.debug.ui.sourcelookup.DsfSourceDisplayAdapter$LookupJob.run(DsfSourceDisplayAdapter.java:203)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
!SUBENTRY 1 org.eclipse.cdt.dsf 4 10002 2022-08-16 18:34:26.755

This is coming from this "task": DsfSourceLookupParticipant.getSourceNameOnDispatchThread()

		IStack stackService = fServicesTracker.getService(IStack.class);
		if (stackService == null) {
			rm.setStatus(new Status(IStatus.ERROR, DsfPlugin.PLUGIN_ID, IDsfStatusConstants.INVALID_HANDLE,
					"Stack data not available", null)); //$NON-NLS-1$
			rm.done();
			return;
		}

Logging is done at: AbstractSourceLookupDirector.doSourceLookup()

	protected List<Object> doSourceLookup(Object element) {
		SourceLookupQuery query = new SourceLookupQuery(element);
		SafeRunner.run(query);
		List<Object> sources = query.getSourceElements();
		Throwable exception = query.getException();
		if (exception != null) {
			if (exception instanceof CoreException) {
				CoreException ce = (CoreException) exception;
				if (ce.getStatus().getSeverity() == IStatus.ERROR) {
					DebugPlugin.log(ce);
				}
			} else {
				DebugPlugin.log(exception);
			}
		}

From debugging one of the affected tests, I see that the source lookup continues despite the launch having been terminated by the test. IMO in that case (there is no launch anymore, so I assume also no stack service), no error should be logged.

Maybe a cancelled status should be set on the result monitor in DsfSourceLookupParticipant.getSourceNameOnDispatchThread(), in case the debug session has ended.

Multiple and confusing errors logged when MBS toolchain description not found

When a CDT user imports an MBS project for which the appropriate toolchain description(s) are not installed, many errors are logged and some may be logged repeatedly within a single workspace session. These log messages do not give a strong indication as to the underlying cause of the problem.

There was discussion on the CDT project call 2022-12-14 regarding adding a single error marker on the project resource describing the underlying problem in user-friendly terms and suppressing other logging in such cases.

Different build configurations may use different toolchains so multiple markers might be required.

Example log on opening a project:

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.396
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.cpp.1578546394" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.cpp.1578546394.372771147"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.398
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.ar.1512874338" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.ar.1512874338.2137206331"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.399
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.objcopy.309454462" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.objcopy.309454462.75600265"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.400
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.objdump.797343514" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.objdump.797343514.1957689281"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.402
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.size.394392036" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.size.394392036.238175312"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.403
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.make.397716147" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.make.397716147.2136059670"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.404
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.rm.1168405050" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.rm.1168405050.842789850"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.405
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.toolchain.id.35641977" for "ilg.gnuarmeclipse.managedbuild.cross.option.toolchain.id.35641977.888888376"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.406
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.warnings.allwarn.1797752127" for "ilg.gnuarmeclipse.managedbuild.cross.option.warnings.allwarn.1797752127.1512929408"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.407
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.warnings.extrawarn.1905949849" for "ilg.gnuarmeclipse.managedbuild.cross.option.warnings.extrawarn.1905949849.735434510"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.408
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.warnings.uninitialized.695206319" for "ilg.gnuarmeclipse.managedbuild.cross.option.warnings.uninitialized.695206319.967132852"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.409
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.lto.1357489954" for "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.lto.1357489954.1501132423"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.412
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.addtools.createflash.1879528410" for "ilg.gnuarmeclipse.managedbuild.cross.option.addtools.createflash.1879528410.1192329015"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.413
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.addtools.createlisting.866363571" for "ilg.gnuarmeclipse.managedbuild.cross.option.addtools.createlisting.866363571.853297297"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.414
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.addtools.printsize.1629639372" for "ilg.gnuarmeclipse.managedbuild.cross.option.addtools.printsize.1629639372.693866778"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.418
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.level.216765706" for "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.level.216765706.502827866"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.419
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.messagelength.352400531" for "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.messagelength.352400531.361094452"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.419
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.signedchar.1747731690" for "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.signedchar.1747731690.1643325207"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.420
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.functionsections.1034375409" for "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.functionsections.1034375409.560983908"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.421
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.datasections.633763633" for "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.datasections.633763633.508802906"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.422
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.debugging.level.811864028" for "ilg.gnuarmeclipse.managedbuild.cross.option.debugging.level.811864028.17661389"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.423
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.debugging.format.1596263961" for "ilg.gnuarmeclipse.managedbuild.cross.option.debugging.format.1596263961.256073443"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.424
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.toolchain.name.246342502" for "ilg.gnuarmeclipse.managedbuild.cross.option.toolchain.name.246342502.1983477626"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.425
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.architecture.931365239" for "ilg.gnuarmeclipse.managedbuild.cross.option.architecture.931365239.1406427066"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.426
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.arm.target.family.1030679276" for "ilg.gnuarmeclipse.managedbuild.cross.option.arm.target.family.1030679276.2031839180"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.427
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.arm.target.instructionset.571448854" for "ilg.gnuarmeclipse.managedbuild.cross.option.arm.target.instructionset.571448854.350673829"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.428
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.prefix.1359090575" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.prefix.1359090575.1594949359"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.429
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.c.1212094163" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.c.1212094163.400276170"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.430
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.cpp.1578546394" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.cpp.1578546394.1999938425"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.431
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.ar.1512874338" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.ar.1512874338.657511821"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.432
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.objcopy.309454462" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.objcopy.309454462.787444763"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.433
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.objdump.797343514" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.objdump.797343514.1483048374"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.434
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.size.394392036" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.size.394392036.676709460"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.435
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.make.397716147" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.make.397716147.657031815"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.435
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.command.rm.1168405050" for "ilg.gnuarmeclipse.managedbuild.cross.option.command.rm.1168405050.457804822"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.436
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.toolchain.id.35641977" for "ilg.gnuarmeclipse.managedbuild.cross.option.toolchain.id.35641977.915092620"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.437
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.warnings.allwarn.1797752127" for "ilg.gnuarmeclipse.managedbuild.cross.option.warnings.allwarn.1797752127.1650842318"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.438
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.warnings.extrawarn.1905949849" for "ilg.gnuarmeclipse.managedbuild.cross.option.warnings.extrawarn.1905949849.2138007193"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.439
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.warnings.uninitialized.695206319" for "ilg.gnuarmeclipse.managedbuild.cross.option.warnings.uninitialized.695206319.1051715996"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.440
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.lto.1357489954" for "ilg.gnuarmeclipse.managedbuild.cross.option.optimization.lto.1357489954.1407848879"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.448
!MESSAGE Missing superclass "ilg.gnuarmeclipse.managedbuild.cross.option.c.compiler.otheroptimizations" for "ilg.gnuarmeclipse.managedbuild.cross.option.c.compiler.otheroptimizations.269534092"

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.586
!MESSAGE Unable to find tool in toolchain=ilg.gnuarmeclipse.managedbuild.cross.toolchain.elf.debug.490388057 for language=org.eclipse.cdt.core.gcc

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.588
!MESSAGE Unable to find compiler command in toolchain=cdt.managedbuild.toolchain.gnu.base

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.590
!MESSAGE Unable to find tool in toolchain=ilg.gnuarmeclipse.managedbuild.cross.toolchain.elf.debug.490388057 for language=org.eclipse.cdt.core.gcc

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.592
!MESSAGE Unable to find tool in toolchain=ilg.gnuarmeclipse.managedbuild.cross.toolchain.elf.debug.490388057 for language=org.eclipse.cdt.core.gcc

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.595
!MESSAGE Unable to find file extension for language org.eclipse.cdt.core.gcc

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.601
!MESSAGE Unable to find tool in toolchain=ilg.gnuarmeclipse.managedbuild.cross.toolchain.elf.debug.490388057 for language=org.eclipse.cdt.core.g++

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.602
!MESSAGE Unable to find compiler command in toolchain=cdt.managedbuild.toolchain.gnu.base

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.603
!MESSAGE Unable to find tool in toolchain=ilg.gnuarmeclipse.managedbuild.cross.toolchain.elf.debug.490388057 for language=org.eclipse.cdt.core.g++

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.604
!MESSAGE Unable to find tool in toolchain=ilg.gnuarmeclipse.managedbuild.cross.toolchain.elf.debug.490388057 for language=org.eclipse.cdt.core.g++

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.606
!MESSAGE Unable to find file extension for language org.eclipse.cdt.core.g++

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.622
!MESSAGE Unable to find tool in toolchain=ilg.gnuarmeclipse.managedbuild.cross.toolchain.elf.debug.490388057 for language=org.eclipse.cdt.core.gcc

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.623
!MESSAGE Unable to find compiler command in toolchain=cdt.managedbuild.toolchain.gnu.base

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.626
!MESSAGE Unable to find tool in toolchain=ilg.gnuarmeclipse.managedbuild.cross.toolchain.elf.debug.490388057 for language=org.eclipse.cdt.core.gcc

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.627
!MESSAGE Unable to find tool in toolchain=ilg.gnuarmeclipse.managedbuild.cross.toolchain.elf.debug.490388057 for language=org.eclipse.cdt.core.gcc

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.627
!MESSAGE Unable to find file extension for language org.eclipse.cdt.core.gcc

!ENTRY org.eclipse.cdt.core 4 0 2022-12-15 13:18:25.759
!MESSAGE Error: Cannot run program "-E": Launching failed

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.973
!MESSAGE Unable to find tool in toolchain=ilg.gnuarmeclipse.managedbuild.cross.toolchain.elf.debug.490388057 for language=org.eclipse.cdt.core.g++

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.974
!MESSAGE Unable to find compiler command in toolchain=cdt.managedbuild.toolchain.gnu.base

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.975
!MESSAGE Unable to find tool in toolchain=ilg.gnuarmeclipse.managedbuild.cross.toolchain.elf.debug.490388057 for language=org.eclipse.cdt.core.g++

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.976
!MESSAGE Unable to find tool in toolchain=ilg.gnuarmeclipse.managedbuild.cross.toolchain.elf.debug.490388057 for language=org.eclipse.cdt.core.g++

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2022-12-15 13:18:25.977
!MESSAGE Unable to find file extension for language org.eclipse.cdt.core.g++

!ENTRY org.eclipse.cdt.core 4 0 2022-12-15 13:18:26.032
!MESSAGE Error: Cannot run program "-E": Launching failed

Improve CDT's setup

I'm doing several things that once. I hope that's okay.

I added a configuration in the same folder as the setup. It's reference via an annotation in the project (so that the setup archiver can discover it and include it in the setups.zip):

The configuration installs the latest available committers product and the workspace includes the main branch of the CDT project setup.

I've simplified the targlet definition:

I've tried as must has possible to use moving target (latest) repos where available so that developers notice problems introduced upstream early when they are first introduced.

This lead to two compile problems in two tests projects that I fixed with package imports and you'll see in the PR.

I've modified the working sets so that there is one per subfolder:

The first working set is any project not part of the subsequent working sets, i.e., currently just the org.eclipse.cdt.root project.

So the workspace now is organized like this:

Plugin dependency should always contain a version range

Since the inclusion of the org.eclipse.tools.templates.* plugins in the CDT repository, the Required-Bundle statement was not updated to include the version range for the plugin that CDT now is providing.

As a consequence, the version of the plugin can be freely chosen as long as the minimum version requirement is fulfilled.

As there might be other plugins that CDT is now providing that is lacking the version range in Required-Bundle part of the MANIFEST.MF file, the org.eclipse.tools.templates mentioned above should only be taken as an example of the problem.

This issue is related to #222.

Old and unreadable dark theme colours

The dark theme syntax colouring is outdated and does not reflect (the current) JDT ones. Enum classes and template parameters are hard to read (which would be resolved by copying them from JDT's type parameters). The doxygen colourings are not necessarily outdated, but I don't see a reason why they would not be the same as Javadoc.

The context assist popups are readable, but have a white background.

More importantly, the console has a white background, until it is focused - the CSS engine changes its colour to what it should be, but the foreground colours remain the same leading to unreadable text.

Another readability issue is the inactive code highlight, which remains white.

Need to hold a write lock to clear result caches assertion error

This test, or one similar to it, has failed a couple of times recently.

This is the detailed output:

Expected number (0) of Non-OK status objects in log differs from actual (1).
 Error while parsing /projC_testTripleLinear/h3.h. java.lang.reflect.InvocationTargetException
junit.framework.AssertionFailedError: 
Expected number (0) of Non-OK status objects in log differs from actual (1).
	Error while parsing /projC_testTripleLinear/h3.h. java.lang.reflect.InvocationTargetException

Caused by: java.lang.reflect.InvocationTargetException
Caused by: java.lang.AssertionError: Need to hold a write lock to clear result caches

The stack trace is incomplete on this, but the assertion is from:

cdt/core/org.eclipse.cdt.core/parser/org/eclipse/cdt/internal/core/index/WritableCIndex.java

Lines 159 to 163 in 10e95a1

	@Override
	public void clearResultCache() {
	assert fIsWriteLocked : "Need to hold a write lock to clear result caches"; //$NON-NLS-1$
	super.clearResultCache();
	}

Hot keys cant be assigned for refactor History / Create script / Apply script

For this:

hot keys can't be assigned. These actions are not listed:

In Java Eclipse all is working fine.

**
Problem is here

https://github.com/eclipse-cdt/cdt/blob/main/core/org.eclipse.cdt.ui/plugin.xml#L1956 where

definitionId references to org.eclipse.ltk.ui.refactor.show.refactoring.history which is defined in org.eclipse.jdt.ui here

https://github.com/eclipse-jdt/eclipse.jdt.ui/blob/master/org.eclipse.jdt.ui/plugin.xml#L2798

But org.eclipse.jdt.ui plugin is not included in CDT installation.

Desktop (please complete the following information):

• OS: Windows
• Version 2022-12

GDBMultiNonStopRunControlTest.testSuspendProcessTwoThreadsRunning[gdbserver] is unstable

This test regularly fails on Jenkins with this error:

Error Message
Timed out waiting for ServiceEvent: org.eclipse.cdt.dsf.mi.service.command.events.MIStoppedEvent
Stacktrace

java.lang.Exception: Timed out waiting for ServiceEvent: org.eclipse.cdt.dsf.mi.service.command.events.MIStoppedEvent
at org.eclipse.cdt.tests.dsf.gdb.tests.nonstop.GDBMultiNonStopRunControlTest.testSuspendProcessTwoThreadsRunning(GDBMultiNonStopRunControlTest.java:3238)

Standard Output
168,523 "testSuspendProcessTwoThreadsRunning[gdbserver]" requesting gdb with gdbserver. Launched gdb 8.1.1.

Consider filtering nested projects from org.eclipse.cdt.root

The org.eclipse.cdt.root contains the entire working tree of the repository. That's of course convenient for making root files and intermediate pom.xml files available in the workspace.

But it also leads to 'duplicate' resources in the workspace. E.g., this search finds two matches but there is really only one underlying file in the file system:

Given the highly regular naming conventions of the project folders, a simple exclusion filter can filter out the contents under nested projects so that you can still see the project names but not the duplicate child content. Search works better then too:

The filter is added/modified like this from the project's properties:

Are you interesting this. I can provide it via a PR if so.

GDB hardware launch assumes ELF executable files have .elf suffix

We should accommodate toolchains that emit ELF executable files with other suffixes when determining whether an image offset can be applied.

Could not set environment for embedded terminal view

When I open the TM terminal view inside Eclipse the environment is set to some pre-defined state.

For running a Java program inside that terminal it would be great if the path to the Java installation could be either defined in the preferences or read from the environment of the user who started Eclipse.

At the moment the path to the Java executable is set to the built in Java distribution of the running Eclipse itself. If I want to use a different version or installation then I have to set it manually in the opened shell every time I open a terminal in Eclipse.

Migrate Eclipse CDT from Gerrit/Bugzilla/etc to GitHub

The Eclipse CDT project is moving to GitHub. We are using this issue to track all the items that need to be completed. Many of the items in this list need to be submitted to webmaster when we are ready at the helpdesk issue

This issue was migrated from eclipse-cdt/cdt-infra#62 that had been used to track the move ahead of us having the new repo

TODO list for the move:

• Create https://github.com/eclipse-cdt/.github
  • Do not enable Issues, Discussions, Wiki - these will all be handled by the main repo https://github.com/eclipse-cdt/cdt
• Create a minimal README.md file in eclipse-cdt/.github that redirects to eclipse-cdt/cdt
• Archive https://github.com/eclipse-cdt/cdt-new-managedbuild-prototype
• Archive https://github.com/eclipse-cdt/cdt-vscode
• Migrate CDT's git repo stored in gerrit to https://github.com/eclipse-cdt/cdt
  • This may be as simple as stopping mirroring https://git.eclipse.org/r/admin/repos/cdt/org.eclipse.cdt,general?
• Rename master branch to main
• Delete/disable https://github.com/eclipse-cdt/cdt wiki
  • This was never used (bar a single/simple page)
  • Proposal/intent is that all documentation is part of the main repo, especially New and Noteworthy
  • See item farther down about future of the Wiki
• Enable Issues and Discussions on https://github.com/eclipse-cdt/cdt
• Set description on https://github.com/eclipse-cdt/cdt to Eclipse CDT™ C/C++ Development Tools
• Make https://git.eclipse.org/r/admin/repos/cdt/org.eclipse.cdt,general readonly
  • There is a lot of stuff on CDT's gerrit that is of differing value. My preferred option to leave CDT's gerrit in read-only state until gerrit is shutdown. That should give plenty of time for people to extract anything of value from gerrit and contribute it to CDT (as a GitHub PR)
• Protect branches from force pushes, deletions and direct pushes
  • All pushes need to be via PR.
• Migrate Process, Policy, etc from Wiki to README.md/CONTRIBUTING.md
• Migrate FAQs and sample code to markdown
• Move N&N pages from Wiki to Help pages https://help.eclipse.org/latest/topic/org.eclipse.cdt.doc.user/concepts/cdt_c_whatsnew.htm or to markdown and update links in cdt_c_whatsnew.htm to point at that markdown
• Move these manual pages from Wiki to Help pages
  • https://wiki.eclipse.org/CDT/Autotools/User_Guide
  • https://wiki.eclipse.org/CDT/StandaloneDebugger
  • https://wiki.eclipse.org/CDT/Meson/User_Guide
• Move CDT Calls pages from Wiki
  • This is the only item I don't know where to put. We could have a wiki just for calls, but I am not keen on Wikis anymore.
• Save old CDT presentations somewhere https://wiki.eclipse.org/CDT:Presentations These will be kept alive as long as the WIki exists, when EF decides to get rid of the wiki we may revisit this.
• Mark all https://wiki.eclipse.org/CDT pages as obsolete or archived with redirections to new pages where possible
  • If there is additional info that needs to be kept, put it somewhere sensible
• Review all links in CDT (especially help) that are to the Wiki and update them
• Move https://github.com/eclipse-cdt/cdt-infra wiki contents to cdt-infra's root README or similar
• Delete/disable https://github.com/eclipse-cdt/cdt-infra wiki
• Redirct https://www.eclipse.org/cdt/ to https://github.com/eclipse-cdt/cdt
  • Maybe one day we can make a new website, many years ago at Kichwa we had an intern make this https://jonahgraham.github.io/cdt-website-prototype/ but the feedback pushed us to not persue it further
  • If we do a new one a Jekyll one similar to have embed CDT does it or just a simple gh-pages one.
• Announce on the Eclipse Forum for C/C++ IDE (CDT) the move to GitHub discussions ahead of shutdown.
• Make the Eclipse Forum for C/C++ IDE (CDT) read-only. The forum will stay open as a user-to-user forum as long as the Eclipse Foundation chooses to run it. Message posted on forum.
• Update CDT.setup - see Bug 580505 and integrate instructions into contributing file.
• Create an issue template
• Create some standard tags
  • Consider a bot to auto tag bugs?
• Create a PR template Created one but it doesn't work?
• Create a discussions template
• Disable new bugs being created in Bugzilla
• Reformat markdown files to one sentence per line as that gives better diffs (meant to do this before merging my big markdown changes but I forgot)
• Merge cdt-infra repo into main cdt repo.
  • Now that many of the security issues are resolved regarding gerrit we should be good to keep the infra code in sync more easily with the main repo.
• Test failures cause Jenkins to report back a failure rather than an unstable state. So we need either better reporting back from Jenkins or find a different solution.

CDT 10.7.1

This is the Release plan and TODO list for above mentioned bug fix release of CDT.

Steps for Release

Items before Release day:

• Discuss with the community a plan and announce it to cdt-dev.
• Create release on PMI
• Update New and Noteworthy page for the bug fix release
  • Add any release notes that are applicable
  • Update bug list search at end of the N&N to include all versions that the N&N applies to
• Update cdt.target to point to new dependency versions
  • This means having cdt.target point at what ever was in the last release. E.g. for CDT 10.6 which requires Eclipse 2022-03, the cdt.target should have the shipped dependencies of 2022-03
  • TODO: Consider making branch versions of CDT simply use https://download.eclipse.org/releases/2022-03/ + any bits that aren't in simrel. That may make this easier.
• Update API baseline to last release and resolve any API errors
  • This means cdt-baseline.target needs have basically the same contents as cdt.target + all the CDT features listed.
• Increment version of all feature.xml, pom.xml and any other place full version is used. (Easiest way is global find and replace, e.g. s/9.9.0/9.10.0/g and review changes.) (See this gerrit for a past example)
• Update comparator.repo in root pom.xml to last release and if there have been any changes since the branch, bump versions of MANIFEST.MFs
• On a branch there should be no Major or Minor version bumps
• Ensure the build is stable - it is always better to release a "Green Dot" build
• Ensure all previous Endgame issues are done.
• Add Target Milestone to GitHub milestones

Items on Release day:

• Promote a cdt build from jenkins to releases
  • CDT Standalone is not released for patches, so STANDALONE should be unchecked
• Smoke test the release by installing it into platform's SDK build.
• Smoke test the release by upgrading from the last C/C++ EPP (Add the new repo into Available Software Sites and then Check for Updates)
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Unmark as keep all old Milestone and RC jobs
• Update composites in releng in preparation for going public on release day
• Promote the files to download - this makes the release public
• Tag the release. Example: git tag -a CDT_9_4_2 2cdc63eae52c8952c0d2543e1e31ca6e25225c4a -m\"CDT 9.4.2\" && git push origin CDT_9_4_2
• Update https://github.com/eclipse-cdt/cdt/blob/main/Downloads.md
• NOTE: Marketplace entries do not need updating for bug fixes as the Marketplace entries are already pointing at the composite release
• Check metadata on PMI (e.g. did release date change?)
• Create a new release entry using the GitHub tooling: https://github.com/eclipse-cdt/cdt/releases/new
• Make an announcement on cdt-dev by forwarding the release entry created above. Example on cdt-dev archives

CDT 11.0.0

This is the Release plan and TODO list for the release in the title. CDT makes its simrel contribution on +1 day in the release cycle (normally Monday by 10pm UTC).

Steps for M1

Items before M1 +1 day:

• Create release on PMI
• Create a milestone on GitHub
• Create New and Noteworthy page for the release
• Prepare for the new release with all these updates: (Note: As I do this work I check the boxes, but I only check the top level one on this line once it is merged)
  • Update cdt.target to point to new dependency versions
  • Synchronize CDT.setup to cdt.target
  • cdt-baseline.target always refers to latest version of CDT. Change this if it isn't appropriate for a specific branch.
  • Add any new features released in latest to cdt-baseline.target
    • In the Problems view you can filter to see only This plug-in is not present in currently active API baseline. by choosing this error filter: "API Problems/Default API Baseline Problem". Ignore any test/example bundles.
  • Update help-docs-eclipserun-repo in root pom.xml and bump versions of all the docs plug-ins
  • Increment version of all feature.xml, pom.xml and any other place full version is used. (Easiest way is global find and replace, e.g. s/9.9.0/9.10.0/g and review changes.) (See bd814fd for a past example)
  • Update comparator.repo in root pom.xml to last release and if there have been any changes since the branch, bump versions of MANIFEST.MFs (If your local java version is the same as the docker container, or if you build in the docker container, a command line like mvn verify -DskipTests -P baseline-compare-and-replace -P build-standalone-debugger-rcp is good to test this has worked and nothing needs updating.)
    • The following need their bundle service segment updated all the time for various reasons:
      • org.eclipse.cdt.debug.application because the version number is encoded in the bundle
  • Update Maven versions (check CI job)
  • Update simrel-site in root pom.xml
  • Remove old API error filters if they are no longer relevant. In the Problems view you can filter to see only these types of problems by selecting only "API Problems/Unused API Problem Filter Problem". (See 1048197 for a past example)
• Ensure the build is stable (on both Jenkins and GitHub actions) - it is always better to release a "Green Dot" build
• Ensure all previous Endgame issues are done.

Items on M1 +0 day:

• update cdt.target to most recent platform

Items on M1 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on M1 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for M2

Items on M2 +0 day:

• update cdt.target to most recent platform

Items on M2 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M1, then STANDALONE can be checked, otherwise do it on +4
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on M2 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for M3

Items on M3 +0 day:

• update cdt.target to most recent platform

Items on M3 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M1, then STANDALONE can be checked, otherwise do it on +4
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on M3 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for RC1

Items before RC1 +1 day:

• Ensure there are no API errors

Items on RC1 +0 day:

• update cdt.target to most recent platform
• update dependencies in MANIFEST.MF to require that platform (see a1febf0 as an example)

Items on RC1 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M1, then STANDALONE can be checked, otherwise do it on +4
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on RC1 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for RC2

These steps should be done before RC2 release, they can be completed at anytime between the last branch creation/release and RC2.

Items before RC2 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes. Note it is probably too late to get a CQ resolved in time for release at this point, so consider mitigation too.
• Create branch for CDT release. Ideally we want to release from the branch.

Items on RC2 +0 day:

• update cdt.target to most recent platform
• update dependencies in MANIFEST.MF to require that platform (see a1febf0 as an example)

Items on RC2 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M1, then STANDALONE can be checked, otherwise do it on +4
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on RC2 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for Release

Items for quiet week (between RC2 and release):

• Ensure release entry on PMI "Release Date" section it says the appropriate "This release is part of Eclipse IDE ??????".
• Make sure documentation is part of simrel's help.

Items to be done 2 days before release:

• Promote a cdt build from jenkins to releases (run twice so standalone is promoted too if needed)
• Add description to the promote-a-build job and the job it promoted.
• Unmark as keep all old Milestone and RC jobs
• Update or create composites in preparation for going public on release day
  • Include the update to latest URL https://download.eclipse.org/tools/cdt/releases/latest/ to point to latest release

Release day:

• Verify we get a GO on the cross-project-issues-dev mailing list
• Promote the files to download - this makes the release public
• Tag the release. Example: git tag -a CDT_9_4_2 2cdc63eae52c8952c0d2543e1e31ca6e25225c4a -m"CDT 9.4.2" && git push origin CDT_9_4_2
• Update Downloads
• Update Marketplace entries:
  • https://marketplace.eclipse.org/node/3799227/edit (Complete C/C++ IDE)
  • https://marketplace.eclipse.org/node/1373403/edit (CDT)
  • https://marketplace.eclipse.org/node/1687099/edit (Terminal)
• Make an announcement on cdt-dev. Example on cdt-dev archives
• Delete download.eclipse.org/tools/cdt/builds for this release
  • Visit https://archive.eclipse.org/tools/cdt/ and press login if the checkboxes and Archive button are not visible
  • Visit https://archive.eclipse.org/tools/cdt/ and delete "builds" if present
  • Visit https://download.eclipse.org/tools/cdt/ and archive "builds"
  • Optional visit https://archive.eclipse.org/tools/cdt/ and delete "builds"
• Using the CBI aggregator tooling update cdt.aggrcon to point to the release as it is not probably pointing to the cdt/builds directory. (e.g. https://git.eclipse.org/r/#/c/154853/)
• Review and discard any "kept forever" builds, especially milestone and superseded RC builds for cdt-master, and jobs on cdt-verify-test-cdt-other-pipeline that were kept around to be tested.
• Update help-docs-eclipserun-repo in root pom.xml (remove -I-builds from path) on the branch and main
• Update target platforms (remove -I-builds from path) on the branch and main

maven bundle for org.apache.commons.io has a different symbolic name

When trying to use a newer Eclipse SDK integration build with CDT 10.7, plugindependencies detects the following problem:

Error: [org.eclipse.cdt.cmake.is.core 1.0.200.202106071842] plugin not found: org.apache.commons.io 2.6.0

This seems to be due to the Bundle-SymbolicName for the Maven bundle being different:

Orbit:

Automatic-Module-Name: org.apache.commons.io
Bundle-SymbolicName: org.apache.commons.io

Maven:

Automatic-Module-Name: org.apache.commons.io
Bundle-SymbolicName: org.apache.commons.commons-io

I assume this will lead to problems at runtime (we can't build with the error above, so we can't test).

Using the Maven bundle is coming from: eclipse-platform/eclipse.platform.releng.aggregator#426

Not all plugins provided by CDT is included in a CDT feature

I noticed that installing an unrelated feature will query the https://download.eclipse.org/tools/cdt/releases/latest update site and download updates for the following plugins:

com.sun.xml.bind_2.3.3.v20221112-0806.jar
jakarta.xml.bind_2.3.3.v20221112-0806.jar
javax.activation_1.2.2.v20221112-0806.jar
javax.xml_1.4.1.v20220503-2331.jar
org.eclipse.tools.templates.core_1.3.0.202211062329.jar
org.eclipse.tools.templates.freemarker_1.3.0.202211062329.jar
org.eclipse.tools.templates.ui_1.4.0.202211062329.jar

It did also download updates for these 2 plugins, but they are covered by 2 features, so not really the same problem.
com.google.gson_2.9.1.v20220915-1632.jar
org.eclipse.launchbar.core_2.5.0.202211062329.jar

For the launchbar, the containing feature can't be used as the core functionality is required by a lot of plugins in CDT, but we do not want the launchbar UI.

`AbstractGNUSourceCodeParser` omits necessary parentheses in asm expressions

Problem Description:

In function asmExpression(StringBuilder), all parentheses are recognized by the parser but omitted then when building the ASM directive:

	protected IToken asmExpression(StringBuilder content) throws EndOfFileException, BacktrackException {
		IToken t = consume(IToken.tLPAREN);
		boolean needspace = false;
		int open = 1;
		while (open > 0) {
			t = consume();
			switch (t.getType()) {
			case IToken.tLPAREN:
				open++;
				break;
			case IToken.tRPAREN:
				open--;
				break;
			case IToken.tEOC:
				throw new EndOfFileException(t.getOffset());

			default:
				if (content != null) {
					if (needspace) {
						content.append(' ');
					}
					content.append(t.getCharImage());
					needspace = true;
				}
				break;
			}
		}
		return t;
	}

However, according to GCC reference Extended Asm,

The enclosing parentheses are a required part of the syntax.

The omitted parathenses would break the syntax, causing the dumped code by ASTWriter not compilable.

Possible Fix:

appending the parentheses to context.

switch (t.getType()) {
  case IToken.tEOC:
    throw new EndOfFileException(t.getOffset());
  case IToken.tLPAREN:
    open++;
  case IToken.tRPAREN:
    open--;
    if (open == 0) break;
  default:
    // appending tokens
}

Create a commit that fixes formatting instead of failing code cleanliness

At the moment if a contributor sends a commit with simple formatting errors we reject the PR because of the code cleanliness check.

Instead of rejecting the PR, what if we pushed a new commit to the PR that simply fixed the formatting?

This came about from a discussion on PR #157

target-async is deprecated

When launching a debug session for a target, the following is printed in the GDB traces:

237,992 13-gdb-set target-async on
238,005 ~"Warning: 'set target-async', an alias for the command 'set mi-async', is deprecated.\n"
238,006 ~"Use 'set mi-async'.\n\n"
238,006 13^done

I suppose we should switch to the mi-async variant instead, but I don't see any easy way to accomplish that without code duplication and/or some kind of API break in the FinalLaunchSequence* classes.

Looking at the GDB sources, it appears it was introduced 329ea57934a9d4b250a0b417af1ec47bc2d0ceb6 and was first included in the GDB 7.8 release.

StringIndexOutOfBoundsException when CMakeListst.txt is missing

CDT cmake core build fails to parse the error.

java.lang.StringIndexOutOfBoundsException: String index out of range: -11
at java.base/java.lang.String.substring(String.java:1841)
at org.eclipse.cdt.cmake.core.internal.CMakeErrorParser$MessageHandler.processMessage(CMakeErrorParser.java:203)
at org.eclipse.cdt.cmake.core.internal.CMakeErrorParser.processMessage(CMakeErrorParser.java:126)
at org.eclipse.cdt.cmake.core.internal.CMakeErrorParser.close(CMakeErrorParser.java:96)

This should produce an error in the problems view instead.

Deadlock in indexer

Something in the recent changes to #79 has caused the indexer to deadlock more readily than before.

Running PDOMCPPBugsTest on the build machine locks up, and it does when running (but not debugging) a significant percentage of the time.

EOL for Qt Plug-ins in CDT 11

For a while now the Qt plug-ins have had at least some issues. They rely on the Nashorn script engine which was removed in Java 15. In theory, before CDT 11 someone could have been using the Qt plug-ins with Java 11 still, even though the packaged Eclipse for C/C++ Developers has been on Java >=15 for ~2 years.

We did a workaround to make the error non-fatal in 2020 when Java 15 came out. I don't know how much of the rest of the Qt features are usable/relevant without the Nashorn script engine.

The last feature/bugfix commit of relevance on Qt was b9c9c44 3+ years ago, but the last real work was back in 2017. Qt was one of Doug's projects, I don't know if QNX/Blackberry relied on it.

Going forward now that we have upped the requirement to Java 17 (in #80) we have to decide what to do about Qt going forward.

core build Autotools projects don't build in CDT 11

Create an Autotools project for Core build - this is the experimental one, and since the changes for watchProcess it fails with:

java.lang.NullPointerException: Cannot invoke "org.eclipse.cdt.core.ICommandLauncher.waitAndRead(java.io.OutputStream, java.io.OutputStream, org.eclipse.core.runtime.IProgressMonitor)" because "this.launcher" is null
	at org.eclipse.cdt.core.build.CBuildConfiguration.watchProcess(CBuildConfiguration.java:524)

full log entry

!ENTRY org.eclipse.core.resources 4 2 2022-10-28 22:34:05.957
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources".
!STACK 0
java.lang.NullPointerException: Cannot invoke "org.eclipse.cdt.core.ICommandLauncher.waitAndRead(java.io.OutputStream, java.io.OutputStream, org.eclipse.core.runtime.IProgressMonitor)" because "this.launcher" is null
	at org.eclipse.cdt.core.build.CBuildConfiguration.watchProcess(CBuildConfiguration.java:524)
	at org.eclipse.cdt.core.autotools.core.AutotoolsBuildConfiguration.execute(AutotoolsBuildConfiguration.java:109)
	at org.eclipse.cdt.core.autotools.core.AutotoolsBuildConfiguration.build(AutotoolsBuildConfiguration.java:68)
	at org.eclipse.cdt.core.build.CBuilder.build(CBuilder.java:45)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1024)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:254)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:311)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:400)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:403)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:362)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:624)
	at org.eclipse.core.internal.resources.Project$1.run(Project.java:571)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2380)
	at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:609)
	at org.eclipse.core.internal.resources.Project.build(Project.java:121)
	at org.eclipse.debug.core.model.LaunchConfigurationDelegate.lambda$0(LaunchConfigurationDelegate.java:406)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2380)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2400)
	at org.eclipse.debug.core.model.LaunchConfigurationDelegate.buildProjects(LaunchConfigurationDelegate.java:412)
	at org.eclipse.debug.core.model.LaunchConfigurationDelegate.buildForLaunch(LaunchConfigurationDelegate.java:122)
	at org.eclipse.launchbar.core.target.launch.LaunchConfigurationTargetedDelegate.superBuildForLaunch(LaunchConfigurationTargetedDelegate.java:61)
	at org.eclipse.cdt.debug.core.launch.CoreBuildLaunchConfigDelegate.buildForLaunch(CoreBuildLaunchConfigDelegate.java:168)
	at org.eclipse.launchbar.ui.internal.commands.BuildActiveCommandHandler$1$1.run(BuildActiveCommandHandler.java:110)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

This appears to be because the CBuildConfiguration assumes that what is being watched was also launched by the build configuration. But in the autotools case it isn't:

cdt/build/org.eclipse.cdt.core.autotools.core/src/org/eclipse/cdt/core/autotools/core/AutotoolsBuildConfiguration.java

Lines 103 to 109 in 10e95a1

	ProcessBuilder builder = new ProcessBuilder(command).directory(dir.toFile());
	setBuildEnvironment(builder.environment());
	try {
	// TODO Error parsers
	Process process = builder.start();
	watchProcess(console, monitor);

AFAICT The regression was introduced with 5e4a66b

However, I think the "real" problem may be that autotools is launching the autoreconf locally, but everything else remotely. I guess it is ok to launch autoreconf locally since it isn't machine dependent(?). Even if it isn't machine dependent, a user may have everything setup remotely, and not even have autoreconf available locally, so running that remotely seems like a good idea.

cdt/build/org.eclipse.cdt.core.autotools.core/src/org/eclipse/cdt/core/autotools/core/AutotoolsBuildConfiguration.java

Lines 68 to 70 in 10e95a1

	execute(Arrays.asList(new String[] { "autoreconf", "--install" }), project.getLocation(), console, monitor); //$NON-NLS-1$ //$NON-NLS-2$
	executeRemote(Arrays.asList(new String[] { "./configure" }), project.getLocation(), console, monitor); //$NON-NLS-1$
	executeRemote(Arrays.asList(new String[] { "make" }), project.getLocation(), console, monitor); //$NON-NLS-1$

To prevent this issue for others, I think having a better error check around launcher is a good idea.

Managed Project: Disabling Makefile Generation should not disable the Tool Settings as Build-in Compiler Settings rely on this

When disabling the Makefile Generation the Tool Settings are deactivated. However the Prefix and Path, as well as the Compiler settings are used by the CDT Cross GCC Build-in Compiler Settings to detect the include paths.

I think at least a warning that the ${COMMAND} needs to be overwritten might be a good idea, as this might otherwise yield unexpected results when cross-compiling.

Any other ideas on how to solve this are welcome.

-.d file created with Core Build Makefiles

1. Create a Makefile Core Build project

2. Add CFLAGS += -MP -MMD to the Makefile created:

3. do a build and a "phantom" -.d file is created:

importSimpleCMakeProject (org.eclipse.cdt.cmake.ui.internal.tests.NewCMakeProjectTest) failed

The test importSimpleCMakeProject (org.eclipse.cdt.cmake.ui.internal.tests.NewCMakeProjectTest) failed is unstable, maybe just since updating to M3 of Orbit?

Project type was not detected ==> expected: <CMake Project> but was: <>
org.opentest4j.AssertionFailedError: Project type was not detected ==> expected: <CMake Project> but was: <>
	at org.eclipse.cdt.cmake.ui.internal.tests.NewCMakeProjectTest.importCMakeProject(NewCMakeProjectTest.java:171)
	at org.eclipse.cdt.cmake.ui.internal.tests.NewCMakeProjectTest.importSimpleCMakeProject(NewCMakeProjectTest.java:141)

CDT 11.1.0

This is the Release plan and TODO list for the release in the title. CDT makes its simrel contribution on +1 day in the release cycle (normally Monday by 10pm UTC).

Steps for M1

Items before M1 +1 day:

• Create release on PMI
• Create a milestone on GitHub
• Create New and Noteworthy page for the release
• Prepare for the new release with all these updates: (Note: As I do this work I check the boxes, but I only check the top level one on this line once it is merged)
  • Update cdt.target to point to new dependency versions
  • Synchronize CDT.setup to cdt.target
  • cdt-baseline.target always refers to latest version of CDT. Change this if it isn't appropriate for a specific branch.
  • Add any new features released in latest to cdt-baseline.target
    • In the Problems view you can filter to see only This plug-in is not present in currently active API baseline. by choosing this error filter: "API Problems/Default API Baseline Problem". Ignore any test/example bundles.
  • Update help-docs-eclipserun-repo in root pom.xml and bump versions of all the docs plug-ins
  • Increment version of all feature.xml, pom.xml and any other place full version is used. (Easiest way is global find and replace, e.g. s/9.9.0/9.10.0/g and review changes.) (See bd814fd for a past example)
  • Update comparator.repo in root pom.xml to last release and if there have been any changes since the branch, bump versions of MANIFEST.MFs (If your local java version is the same as the docker container, or if you build in the docker container, a command line like mvn verify -DskipTests -P baseline-compare-and-replace -P build-standalone-debugger-rcp is good to test this has worked and nothing needs updating.)
    • The following need their bundle service segment updated all the time for various reasons:
      • org.eclipse.cdt.debug.application because the version number is encoded in the bundle
  • Update Maven versions (check CI job)
  • Update simrel-site in root pom.xml
  • Remove old API error filters if they are no longer relevant. In the Problems view you can filter to see only these types of problems by selecting only "API Problems/Unused API Problem Filter Problem". (See 1048197 for a past example)
• Ensure the build is stable (on both Jenkins and GitHub actions) - it is always better to release a "Green Dot" build
• Ensure all previous Endgame issues are done.

Items on M1 +0 day:

• update cdt.target to most recent platform

Items on M1 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on M1 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for M2

Items on M2 +0 day:

• update cdt.target to most recent platform

Items on M2 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M1, then STANDALONE can be checked, otherwise do it on +4
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on M2 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for M3

Items on M3 +0 day:

• update cdt.target to most recent platform

Items on M3 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M1, then STANDALONE can be checked, otherwise do it on +4
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on M3 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for RC1

Items before RC1 +1 day:

• Ensure there are no API errors

Items on RC1 +0 day:

• update cdt.target to most recent platform
• update dependencies in MANIFEST.MF to require that platform (see a1febf0 as an example)

Items on RC1 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M1, then STANDALONE can be checked, otherwise do it on +4
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on RC1 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for RC2

These steps should be done before RC2 release, they can be completed at anytime between the last branch creation/release and RC2.

Items before RC2 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes. Note it is probably too late to get a CQ resolved in time for release at this point, so consider mitigation too.
• Create branch for CDT release. Ideally we want to release from the branch.

Items on RC2 +0 day:

• update cdt.target to most recent platform
• update dependencies in MANIFEST.MF to require that platform (see a1febf0 as an example)

Items on RC2 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M1, then STANDALONE can be checked, otherwise do it on +4
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on RC2 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for Release

Items for quiet week (between RC2 and release):

• Ensure release entry on PMI "Release Date" section it says the appropriate "This release is part of Eclipse IDE ??????".
• Make sure documentation is part of simrel's help.
• Review closed issues and merged PRs to make sure labels and milestones are accurate
• Review the New and Noteworthy for content

Items to be done 2 days before release:

• Promote a cdt build from jenkins to releases (run twice so standalone is promoted too if needed)
• Add description to the promote-a-build job and the job it promoted.
• Unmark as keep all old Milestone and RC jobs
• Update or create composites in preparation for going public on release day
  • Include the update to latest URL https://download.eclipse.org/tools/cdt/releases/latest/ to point to latest release

Release day:

• Verify we get a GO on the cross-project-issues-dev mailing list
• Promote the files to download - this makes the release public
• Tag the release. Example: git tag -a CDT_9_4_2 2cdc63eae52c8952c0d2543e1e31ca6e25225c4a -m"CDT 9.4.2" && git push origin CDT_9_4_2
• Update Downloads
• Update Marketplace entries:
  • https://marketplace.eclipse.org/content/complete-eclipse-cc-ide/edit (Complete C/C++ IDE)
  • https://marketplace.eclipse.org/content/eclipse-cc-ide/edit (CDT)
  • https://marketplace.eclipse.org/content/tm-terminal/edit (Terminal)
• Make an announcement on cdt-dev. Example on cdt-dev archives
• Delete download.eclipse.org/tools/cdt/builds for this release
  • Visit https://archive.eclipse.org/tools/cdt/ and press login if the checkboxes and Archive button are not visible
  • Visit https://archive.eclipse.org/tools/cdt/ and delete "builds" if present
  • Visit https://download.eclipse.org/tools/cdt/ and archive "builds"
  • Optional visit https://archive.eclipse.org/tools/cdt/ and delete "builds"
• Using the CBI aggregator tooling update cdt.aggrcon to point to the release as it is not probably pointing to the cdt/builds directory. (e.g. https://git.eclipse.org/r/#/c/154853/)
• Review and discard any "kept forever" builds, especially milestone and superseded RC builds for cdt-master, and jobs on cdt-verify-test-cdt-other-pipeline that were kept around to be tested.
• Update help-docs-eclipserun-repo in root pom.xml (remove -I-builds from path) on the branch and main
• Update target platforms (remove -I-builds from path) on the branch and main

org.eclipse.cdt.docker.launcher uses deprecated (and now removed) API

eclipse-platform/eclipse.platform.ui#323 removed the deprecated class org.eclipse.jface.databinding.viewers.ViewersObservables <-- link to file before it was deleted so you can read the @deprecated instructions.

Eclipse shows "Invalid Overload" and red underline for legal code.

For the following code:

#include <cctype>
#include <algorithm>
#include <string>

bool isUpper(const std::string& s)
{
  return std::find_if(s.begin(), s.end(), std::islower) == s.end(); 
}

Eclipse CDT (Version: 10.7.0.202206081808, Build id: 20220608-1808) shows a red underline for "std::islower". If I hover over it, Eclipse complains "invalid overload of std::islower".

However, the code compiles and runs fine.

If I remove the 'std' prefix and use "::islower" instead, Eclipse stops complaining.

If I add an actual call to std::islower (e.g. "bool b = std::islower('a');" Eclipse seems to find nothing wrong with that line. It is only when the address of the function is taken, implicitly or explicitly, that Eclipse seems to think there is a problem. For instance, "auto x = std::islower;" shows a red underline, but "auto y = ::islower;" does not.

"No Toolchain found for Target Local" for managed build after compiling cmake

In a new CDT install (I just downloaded eclipse-cpp-2022-06-R-win32-x86_64.zip to confirm it is also present in the release)
With a make and gcc compiler in the path but no cmake tools in the path
Start CDT
Create the managed build hello world project.
Build the project. (It should build fine)
Now create a cmake project and build. The build fails (which is normal as no cmake is available)
Rebuild the hello world project.
I get a "No Toolchain found for Target Local" error.

I have not found a way out of this situation yet.

Test stability umbrella bug

This is a list of known unstable tests since we moved to Java 17 + GitHub Actions.

If you have a failing test in your GitHub actions, please check it against this list. If the test looks unstable, add it to this list (or make a comment requesting a committer do that).

• MIBreakpointsTest.insertDprintfBreakpoint[gdbserver] #115
• LanguageSettingsListenersTests.testNotification_globalProvider_SerializeEntries #118
• ResourceLookupTests.testResourceDelta #120
• GDBMultiNonStopRunControlTest.testSuspendProcessTwoThreadsRunning[gdbserver] #119
• MIExpressionsNonStopTest.testLocalVariables[gdbserver] Haven't seen this fail in a while and have now lost the stack trace of the last fail
• BuildDescriptionModelTests.testDesRebuildStateWithCustomBuildStep #118
• 50+ tests in org.eclipse.cdt.ui.tests.text.contentassist2 on GitHub actions (only?) #118
• testDescriptorCreation (org.eclipse.cdt.core.cdescriptor.tests.CDescriptorOldTests) #118
• testClassInUnnamedNamespace (org.eclipse.cdt.internal.index.tests.IndexSearchTest) #120
• testCommonSDK (org.eclipse.cdt.internal.pdom.tests.PDOMProviderTests) #120
• testTripleLinear (org.eclipse.cdt.internal.index.tests.IndexCompositeTests) #128
• testModelBuilderBug222398 (org.eclipse.cdt.core.model.tests.CModelBuilderBugsTest) #128
• testModelBuilderBug262785 (org.eclipse.cdt.core.model.tests.CModelBuilderBugsTest) #128
• testModelBuilderBug274490 (org.eclipse.cdt.core.model.tests.CModelBuilderBugsTest) #128
• testGdbSyncServiceCanSwitchGDBStackFrame[gdb] (org.eclipse.cdt.tests.dsf.gdb.tests.nonstop.ThreadStackFrameSyncTest) with error #120

Internal error while trying to serialize language settings Resource '/noFilesToBuild' does not exist.

When running test cases sometimes I see:

Internal error while trying to serialize language settings Resource '/noFilesToBuild' does not exist.

as part of the failing test.

e.g.:

test30NoFilesToBuild (org.eclipse.cdt.managedbuilder.core.tests.ManagedProject30MakefileTests) failed

Expected number (0) of Non-OK status objects in log differs from actual (1).
 Internal error while trying to serialize language settings Resource '/noFilesToBuild' does not exist.
Stack Trace
org.eclipse.core.internal.resources.ResourceException(/noFilesToBuild)[368]: java.lang.Exception: Resource '/noFilesToBuild' does not exist.
 at org.eclipse.core.internal.resources.ResourceException.provideStackTrace(ResourceException.java:42)
 at org.eclipse.core.internal.resources.ResourceException.<init>(ResourceException.java:38)
 at org.eclipse.core.internal.resources.Resource.checkExists(Resource.java:330)
 at org.eclipse.core.internal.resources.Resource.checkAccessible(Resource.java:204)
 at org.eclipse.core.internal.resources.Project.checkAccessible(Project.java:150)
 at org.eclipse.core.internal.resources.Folder.assertCreateRequirements(Folder.java:36)
 at org.eclipse.core.internal.resources.Folder.create(Folder.java:94)
 at org.eclipse.core.internal.resources.Folder.create(Folder.java:122)
 at org.eclipse.cdt.internal.core.language.settings.providers.LanguageSettingsProvidersSerializer.serializeLanguageSettings(LanguageSettingsProvidersSerializer.java:909)
 at org.eclipse.cdt.internal.core.settings.model.xml.XmlProjectDescriptionStorage$DesSerializationRunnable.run(XmlProjectDescriptionStorage.java:178)
 at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager$CompositeWorkspaceRunnable.run(CProjectDescriptionManager.java:204)
 at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager$CompositeWorkspaceRunnable.run(CProjectDescriptionManager.java:204)
 at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager$5.run(CProjectDescriptionManager.java:508)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2380)
 at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.runAtomic(CProjectDescriptionManager.java:504)
 at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager$4.run(CProjectDescriptionManager.java:484)
 at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
junit.framework.AssertionFailedError: 
Expected number (0) of Non-OK status objects in log differs from actual (1).
	Internal error while trying to serialize language settings Resource '/noFilesToBuild' does not exist.
Stack Trace
org.eclipse.core.internal.resources.ResourceException(/noFilesToBuild)[368]: java.lang.Exception: Resource '/noFilesToBuild' does not exist.
	at org.eclipse.core.internal.resources.ResourceException.provideStackTrace(ResourceException.java:42)
	at org.eclipse.core.internal.resources.ResourceException.<init>(ResourceException.java:38)
	at org.eclipse.core.internal.resources.Resource.checkExists(Resource.java:330)
	at org.eclipse.core.internal.resources.Resource.checkAccessible(Resource.java:204)
	at org.eclipse.core.internal.resources.Project.checkAccessible(Project.java:150)
	at org.eclipse.core.internal.resources.Folder.assertCreateRequirements(Folder.java:36)
	at org.eclipse.core.internal.resources.Folder.create(Folder.java:94)
	at org.eclipse.core.internal.resources.Folder.create(Folder.java:122)
	at org.eclipse.cdt.internal.core.language.settings.providers.LanguageSettingsProvidersSerializer.serializeLanguageSettings(LanguageSettingsProvidersSerializer.java:909)
	at org.eclipse.cdt.internal.core.settings.model.xml.XmlProjectDescriptionStorage$DesSerializationRunnable.run(XmlProjectDescriptionStorage.java:178)
	at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager$CompositeWorkspaceRunnable.run(CProjectDescriptionManager.java:204)
	at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager$CompositeWorkspaceRunnable.run(CProjectDescriptionManager.java:204)
	at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager$5.run(CProjectDescriptionManager.java:508)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2380)
	at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.runAtomic(CProjectDescriptionManager.java:504)
	at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager$4.run(CProjectDescriptionManager.java:484)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)



Caused by: org.eclipse.core.internal.resources.ResourceException: Resource '/noFilesToBuild' does not exist.
Caused by: java.lang.Exception: Resource '/noFilesToBuild' does not exist.

Follow-on from #117

Black Magic Probe's `run` causes race condition with CDT leading to debug commands not working

Hi,
In the startup page of my GDB hardware debug configuration, I didn't click "resume". Instead I put "-exec-run" in the text area. ("continue" skip the softdevice initialization of my nrf52833, so no good).
If there is no breakpoint at all, it's working well. I can stop and resume the process and do variable exploration and everything.
If there is some breakpoint, for example in the main function, the debug commands (continue, stop, step, etc.) doesn't work anymore. Eclipse is confused. Sometime the debug view show that the process is running but the debugger console says it is stopped. Sometime Eclipse become totally unresponsive (killing gdb process gives back control of Eclipse).
I've noticed that if I put a delay (TimeUnit.SECONDS.sleep(2)) at the beginning of org.eclipse.cdt.dsf.mi.service.MIBreakpointsManager.doUninstallBreakpoint(), the control problem disappear.
So I think there is a race condition somewhere. I don't think I can find that by myself. Any help ?

PS : I can explain more, make a screencast or anything needed to help finding that bug.

Searching for binary scans the entire project

It could be useful to restrict to a relevant path th search for bynaries build stage.
We a have a big project with some configuration that builld small part of the project.
It would be great to configure the path for serch bynaries in the configuration settings.
perhaps it could be configured as in output location ?

Future of org.eclipse.cdt.debug.dap and org.eclipse.cdt.lsp

With CDT 11 approaching I am trying to thin out some of the parts of CDT that are not being maintained so that they aren't ongoing maintenance and API burdens (e.g recent removal of Qt plug-ins and soon to be merged removal of old binary parsers).

We have a lot of experimental code sitting around CDT, started projects or Proof of Concepts.

One of these is the CDT provided Language Sever + Debug Adapter support. These are critical technologies for the future of Language support in Eclipse, but what we have in CDT is not maintained. It sometimes interferes with normal CDT operations and I am not convinced it works or is well enough documented.

The last non-refactoring / non-releng changes on LSP part has been:

• 4a3e046dd which reduced the interference of CDT LSP in normal C/C++ Editor in Aug 2020
• 8c78a241d which was to improve cquery support in 2018, this came in just after Manish's work during GSoC in summer 2018.

As for the DAP implementation, that was a PoC that no one other than me looked at and it is not maintained.

Therefore, for CDT 11 I propose removing this code from CDT. If anyone is looking at picking up this work in the future I would support this code being included again in the future. 

To be clear - the future of C/C++ support in Eclipse requires a (probably) clangd backed language server. But this requires some investment that hasn't been made by anyone in CDT as of now.

@ruspl-afed I have explicitly cc'ed you as you are the only active committer to have touched this code since 2018.

Adding New Folders to C Projects

Currently using 2022-09 (4.25.0) / CDT 10.7.1 / macOS 10.15.7

Seeking clarification:

This has confused me forever. Neither docs, experiments, nor Google have been able to shed light.

Whenever I add a new folder within the source code project, I have to go into project Properties > C/C++ Build > Tool Settings > GCC C Compiiler > Includes and manually add the full folder path into the list.

I have tried use the project contextual menu to add "Source Folder," but that doesn't even add the folder where I want it. Regardless of the level of parent folder I select to add a folder to, the Source Folder option always puts the folder at the root of the project. So, obviously that has some special purpose.

It just seems to me that adding a folder, just like adding a new header file, should be something that is added to the project automatically.

Is this manual intervention for folders really required, or have I somehow missed configuring something correctly?

Thanks.
-- greg

Update CDT to Java 17 for building and running

On CDT's next major version, CDT 11.0, CDT will require Java 17 to build and run. Eclipse IDE for C/C++ Developers has shipped with Java 17 for a while already, and more and more of CDT's dependencies also require Java 17.

This was announced on the mailing list back in June and has been discussed repeatedly on CDT monthly calls.

The Build machine was upgraded to have Java 17 available to build CDT a little while ago: eclipse-cdt/cdt-infra@dd95d63.

What is left is to update BREE of all bundles to Java 17 and make any other related changes.

find operation in terminal

It could be very usefull to find strings in terminal logs

GDB 12 behaviour changes cause false negatives in test report

GDB 12 has some welcome behaviour changes, especially around floating point values. See 574110 for more details on that.

There is a gerrit which is WIP on updating the CDT tests to work with GDB 12 that hasn't been integrated yet.

GitHub actions recently changed ubuntu-latest to being Ubuntu 22.04, which means our tests now run against GDB 12 and we get lots of false negative test results.

CDT failed to parse some preprocessed c code

I am trying use CDT as a frontend of my project, but it seems that the parser cannot correctly generate AST of some preprocessed c code.

extern __inline unsigned long long
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
_mulx_u64 (unsigned long long __X, unsigned long long __Y,
    unsigned long long *__P)
{
  unsigned __int128 __res = (unsigned __int128) __X * __Y;
  *__P = (unsigned long long) (__res >> 64);
  return (unsigned long long) __res;
}

int main() {
    unsigned long long x = 10;
    unsigned long long y = 10;
    unsigned long long z;
    _mulx_u64(x, y, &z);
    return z;
}

This is a piece of the code for demo. The code is genenrated by gcc -E some-code.c, and is both compilable by gcc and clang .

In detail,

1. I invoke the parser by the following code:

        FileContent fileContent = FileContent.createForExternalFileLocation("../../../../test.c");
        IScannerInfo scannerInfo = new ScannerInfo(new HashMap<>(), new String[0]);
        IParserLogService log = new DefaultLogService();
        IncludeFileContentProvider emptyIncludes = IncludeFileContentProvider.getEmptyFilesProvider();
        int opts = 0;
        IASTTranslationUnit tu;
        tu = GCCLanguage.getDefault().getASTTranslationUnit(fileContent, scannerInfo, emptyIncludes, null, opts, log);
// some other traversing
        System.out.println(new ASTWriter().write(tu));

2. ASTWriter fails with the following pasing problem:

Missing ; in file: /.../test.c:6

3. Environment: OS: macOS 12.6; JDK: Oracle JDK 11.0.14; gcc: Homebrew GCC 11.3.0_1; clang: Apple clang 13.1.6
4. I have posted a demo project at https://github.com/Neuromancer42/cdt-parser-demo (This is a bnd-workspace project, not a standard eclipse plugin project). The project can be built and run by executing ./gradlew run.cdtdemo in the project root.

Formatter breaks code containing macros

Using C/C++ Development Tools SDK 10.7.1.202208222120.

• With the file in editor below
• select all lines
• trigger formatting via Ctrl+Shift+F

/*
 * CodeFormatTest.cpp
 */
#define s
#define ms *1.0
class CodeFormatTest{
public:
        void methodWithParam(double d){

        }

        void test(){
                methodWithParam(1 s);
                methodWithParam(1 ms);
        }

};

This will produce this (broken, not compilable) code (note missing space between 1 and ms inside methodWithParam(1ms);)

/*
 * CodeFormatTest.cpp
 */
#define s
#define ms *1.0
class CodeFormatTest {
public:
  void methodWithParam(double d)
  {

  }

  void test()
  {
    methodWithParam(1 s);
    methodWithParam(1ms);
  }

};

Editor whitespace as double-clickable

It would be very useful (productive) to have white space be double-clickable as a word.

This is a common capability in Mac software, so in all my other editors and even word processor do this, and I find myself auto-piloting in Eclipse, but having to do more difficult keyboarding which takes longer. (All small differences of course, but still noticable in the work flow.)

Let me explain...

If we look at the code fragment below, the text is aligned in pseudo columns. Let's say that the word Length needs to change to Size, so that delimiterLength becomes delimiterSize, and csvStringLength becomes csvStringSize. Let's also say we change elements to members, and maxLimit to stringLimit.

struct mCsvList {
    size_t          elementLimit;       // Max allowed size of the text for each element.
    size_t          maxLimit;           // Max allowed size of the joined CSV string.
    const char*     delimiter;          // Copy of delimiter.
    size_t          delimiterLength;    // Store to avoid having to calculate it repeatedly.
    char*           csvString;          // Final cleaned up CSV string.
    size_t          csvStringLength;    // Size of the final CSV string.
    char**          elements;           // The internal array of value elements.
    size_t*         elementSizes;       // The size of each array element string.
    unsigned int    count;              // The number of elements.
};

After refactoring, we get this. Now it's time to realign the comments. Many ways to do that.

struct mCsvList {
    size_t          elementLimit;       // Max allowed size of the text for each element.
    size_t          stringLimit;           // Max allowed size of the joined CSV string.
    const char*     delimiter;          // Copy of delimiter.
    size_t          delimiterSize;    // Store to avoid having to calculate it repeatedly.
    char*           csvString;          // Final cleaned up CSV string.
    size_t          csvStringSize;    // Size of the final CSV string.
    char**          members;           // The internal array of value elements.
    size_t*         memberSizes;       // The size of each array element string.
    unsigned int    count;              // The number of elements.
};

What I find the fastest (not necessarily the fewest key strokes) in my other editors is that I double click in the white space gap, and press tab as needed to realign. So, double click in the gap of stringLimit; // Max will select the entire white space between ";" and "/" just like double-clicking a word. It's a very quick right hand on the mouse double-clicking the affected gaps, and left hand whacking Tab.

I use this without even thinking about it in so many places. I suspect there's better examples, but this is what popped into my head. Oh — even when mouse navigating around reading things, I might spot a place with extra spaces, I just double-click, hit Space or Tab, and done — vs. having to drag, or use shift-command-arrow key combinations to make a wide selection.

It surprises me that it's not a universal mouse behavior like word selecting. In Microsoft-land, Word doesn't do it, but Visual Studio Code does. Notepad tries to but it differentiates tabs vs spaces (defeats the purpose). Adobe doesn't do it in InDesign copy text, but in any of the user interface fields like creating a new Stye name, it does (probably leaning on standard Apple behavior there).

I don't know if it is something that can be added to CDT alone, or if you have to lobby for support all the way up the food chain. It is a small but productive selection behavior that I would find very useful in the Eclipse editor.

Thanks for all your work.

-- greg

Can't install CDT due to JavaSE dependency

CDT won't install on Eclipse 2022-12 due to a dependency to JavaSE not satisfied.

Steps to reproduce the behavior:

1. Downloading Eclipse SDK 4.26
2. Install CDT from Help -> Install New Software...

Expected behavior
Install CDT.

Desktop:

• OS: Ubuntu
• Browser: Firefox
• Version: 22-04 LTS

Additional context

java --version
openjdk 11.0.17 2022-10-18
OpenJDK Runtime Environment (build 11.0.17+8-post-Ubuntu-1ubuntu222.04)
OpenJDK 64-Bit Server VM (build 11.0.17+8-post-Ubuntu-1ubuntu222.04, mixed mode, sharing)

Cannot complete the install because some dependencies are not satisfiable
  Software being installed: a.jre.javase 18.0.0
  Software being installed: C/C++ Development Tools 11.0.0.202211300214 (org.eclipse.cdt.feature.group 11.0.0.202211300214)
  Cannot satisfy dependency:
    From: C/C++ Development Tools 11.0.0.202211300214 (org.eclipse.cdt.feature.group 11.0.0.202211300214)
    To: org.eclipse.equinox.p2.iu; org.eclipse.cdt.platform.feature.group [11.0.0.202211300214,11.0.0.202211300214]
  Cannot satisfy dependency:
    From: C/C++ Standard make Build Core 7.6.0.202211062329 (org.eclipse.cdt.make.core 7.6.0.202211062329)
    To: osgi.ee; (&(osgi.ee=JavaSE)(version=17))
  Cannot satisfy dependency:
    From: C/C++ Development Platform 11.0.0.202211300214 (org.eclipse.cdt.platform.feature.group 11.0.0.202211300214)
    To: org.eclipse.equinox.p2.iu; org.eclipse.cdt.make.core [7.6.0.202211062329,7.6.0.202211062329]