eclipse-cdt / cdt Goto Github PK
View Code? Open in Web Editor NEWEclipse CDT™ C/C++ Development Tools
Home Page: http://eclipse.org/cdt
License: Eclipse Public License 2.0
Eclipse CDT™ C/C++ Development Tools
Home Page: http://eclipse.org/cdt
License: Eclipse Public License 2.0
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.
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).
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.
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
}
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:
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).
Items before M1 +1 day:
latest
version of CDT. Change this if it isn't appropriate for a specific branch.latest
to cdt-baseline.target
help-docs-eclipserun-repo
in root pom.xml and bump versions of all the docs plug-inss/9.9.0/9.10.0/g
and review changes.) (See bd814fd for a past example)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.)
org.eclipse.cdt.debug.application
because the version number is encoded in the bundlesimrel-site
in root pom.xmlItems on M1 +0 day:
Items on M1 +1 day:
Items on M1 +4 day (or shortly after):
Items on M2 +0 day:
Items on M2 +1 day:
Items on M2 +4 day (or shortly after):
Items on M3 +0 day:
Items on M3 +1 day:
Items on M3 +4 day (or shortly after):
Items before RC1 +1 day:
Items on RC1 +0 day:
Items on RC1 +1 day:
Items on RC1 +4 day (or shortly after):
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:
Items on RC2 +0 day:
Items on RC2 +1 day:
Items on RC2 +4 day (or shortly after):
Items for quiet week (between RC2 and release):
Items to be done 2 days before release:
Release day:
git tag -a CDT_9_4_2 2cdc63eae52c8952c0d2543e1e31ca6e25225c4a -m"CDT 9.4.2" && git push origin CDT_9_4_2
help-docs-eclipserun-repo
in root pom.xml
(remove -I-builds
from path) on the branch and main-I-builds
from path) on the branch and mainUsing C/C++ Development Tools SDK 10.7.1.202208222120.
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);
}
};
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:
master
branch to main
Eclipse CDT™ C/C++ Development Tools
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.
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.:
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
Even with the fixes in #117 I am still seeing tests in org.eclipse.cdt.ui.tests.text.contentassist2.PlainC_CompletionTests fail too often.
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:
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.
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):
We should accommodate toolchains that emit ELF executable files with other suffixes when determining whether an image offset can be applied.
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.
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:
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
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.
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.
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)
!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:
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.
To prevent this issue for others, I think having a better error check around launcher is a good idea.
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.
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 won't install on Eclipse 2022-12 due to a dependency to JavaSE not satisfied.
Steps to reproduce the behavior:
Expected behavior
Install CDT.
Desktop:
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]
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.
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.
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
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,
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));
Missing ; in file: /.../test.c:6
./gradlew run.cdtdemo
in the project root.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.cBuilding 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)
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.
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.
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.
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.
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
This is the Release plan and TODO list for above mentioned bug fix release of CDT.
Items before Release day:
s/9.9.0/9.10.0/g
and review changes.) (See this gerrit for a past example)comparator.repo
in root pom.xml to last release and if there have been any changes since the branch, bump versions of MANIFEST.MFsItems on Release day:
git tag -a CDT_9_4_2 2cdc63eae52c8952c0d2543e1e31ca6e25225c4a -m\"CDT 9.4.2\" && git push origin CDT_9_4_2
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.
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.
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:
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:
cmake -G "Eclipse CDT4 - Ninja" --toolchain {toolchain-file} -DCMAKE_BUILD_TYPE=Debug -B ../eclipse_project .
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
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).
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.
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.
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
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
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).
Items before M1 +1 day:
latest
version of CDT. Change this if it isn't appropriate for a specific branch.latest
to cdt-baseline.target
help-docs-eclipserun-repo
in root pom.xml and bump versions of all the docs plug-inss/9.9.0/9.10.0/g
and review changes.) (See bd814fd for a past example)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.)
org.eclipse.cdt.debug.application
because the version number is encoded in the bundlesimrel-site
in root pom.xmlItems on M1 +0 day:
Items on M1 +1 day:
Items on M1 +4 day (or shortly after):
Items on M2 +0 day:
Items on M2 +1 day:
Items on M2 +4 day (or shortly after):
Items on M3 +0 day:
Items on M3 +1 day:
Items on M3 +4 day (or shortly after):
Items before RC1 +1 day:
Items on RC1 +0 day:
Items on RC1 +1 day:
Items on RC1 +4 day (or shortly after):
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:
Items on RC2 +0 day:
Items on RC2 +1 day:
Items on RC2 +4 day (or shortly after):
Items for quiet week (between RC2 and release):
Items to be done 2 days before release:
Release day:
git tag -a CDT_9_4_2 2cdc63eae52c8952c0d2543e1e31ca6e25225c4a -m"CDT 9.4.2" && git push origin CDT_9_4_2
help-docs-eclipserun-repo
in root pom.xml
(remove -I-builds
from path) on the branch and main-I-builds
from path) on the branch and mainIt 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
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.
It could be very usefull to find strings in terminal logs
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
We are using parallel to run tests + code cleanliness in parallel. But this is causing deadlock on the build machine.
Line 9 in 2089c1d
The reason is that the outer agent request:
Line 2 in 2089c1d
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 ?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.