2023-03 Post update problems

[jarsudsco]

First post in this forum so please excuse any mistakes on my part.

My Eclipse installation recently updated to 2023-03. I dread the quarterly updates as they always cause me problems. As a very quick summary I use Eclipse for native C/C++, Arduino/ESP8266 (sloeber), ESP32 (Espressif IDE) AVR (AVR Eclipse), Java and Python (Pydev). I also have Devstyle, and IndentGuide installed.

I've recently been working mainly on AVR projects which I've always had problems creating (the nature is not correctly set for one thing) but once I get one to the stage it will build it seems to remain stable. Yesterday, I had need to write some plain C++ to test something. Creating a new C++ project failed. Opening an existing project appeared to work but the projects show no contents (they do exist on-disk). Unsurprisingly attempting to build such an existing projects also fails. The errors are all similar, I'll try and attach an image of the build failure but they refer to Cannot invoke "Object.equals(Object)" because "o" is null.

Any suggestions would be appreciated. I'm happy to try to provide any other info that might be useful.

Thanks.

[jantje]

1. ESP32 IDF https://github.com/espressif/idf-eclipse-plugin/blob/master/README.md
   "Eclipse IDE for C/C++ Developers 2022-09 (2021-06 to 2022-09 should work fine. 2022-12 is not yet supported"
   So that is at least one plugin stating it won't work.

2)I haven't tested Sloeber yet on the latest CDT version so I do not know whether that will work, but issues have been reported in this area.

3)If the avr plugin you installed is this one https://avr-eclipse.sourceforge.net/wiki/index.php/Plugin_Download
That is a plugin Sloeber started from. There used to be incompatibilities and there probably still are.

It looks to me that you have put together a lot of plugins and therefore created a very unique situation.
As all these plugins are supported by different people no one has any experience with your setup and as such no one can really help you.
Even inside CDT everybody focusses on a very limited set of functionality. So if you say "Creating a new C++ project failed." the return question is "what type of C++ project" Is it a managed build project or a Cmake project or a project with make file?

So my advice: as you seem to have a problem creating a standard CDT project create the project in a standard CDT install. If it works you know the problem only occurs when one of the additional plugins is installed. If it doesn't work you may have found a CDT issue.

[jarsudsco]

Thank you for the reply jantje, I do appreciate your points but the greatest benefit of Eclipse for me is I can switch between native C/C++, Arduino and AVR easily and again whilst I take your point nobody has said this can’t or shouldn’t be done, and I assumed there is a process for narrowing down the source of faults between different components.

I was aware of the ESP32 situation after the 2022-12 upgrade. I’m not certain which AVR plug-in I’m using as I’m currently not at my desk. And I’ve not checked Sloeber yet as I needed to concentrate on the AVR project. And I don’t think I’ve ever had an issue with Python or Java :-)

I knew there would not be sufficient info in my post but didn’t want to post pages of stuff that nobody wanted to see. I’ll follow up asap.

Thank you again.

[jonahgraham]

Is there an error message in the log with a full stack trace. A null pointer in the new project wizard is pretty critical so resolving this will be a priority. If the problem is in cdt we will do a near immediate release too.

[jarsudsco]

Thanks for the reply. I’m not at my desk currently but will try to check the log asap.

[jarsudsco]

Jonah, I did find the error log but noticed a number of errors preceding the one I actually posted referring to the toolchain:

!ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2023-03-18 21:24:12.569
!MESSAGE Exception in toolchain [MinGW GCC], id=cdt.managedbuild.toolchain.gnu.mingw.exe.debug.1770667898

When I checked there were (and still are) no toolchains configured despite me having had MinGW installed and being used for a long time.

I took jantje's advice and installed a fresh copy of 2023-03 and again the MinGW toolchain was not found. I'll attach a screen grab of the new install showing no toolchains with a terminal window showing the system path including "C:\Tools\MinGW\bin" and a "gcc --version".

I did go on and try to create a C++ managed build project called "test-proj", forcing it to use MinGW and unsurprisingly perhaps it failed in the same way as in my OP. I'll attach the log of that session.

new_install.log

I have a seldom used laptop that has Eclipse 2022-06 on it, set up as far as I can tell in exactly the same way as my others, except I also added MinGW64. And just by changing the system path, that Eclipse happily finds and uses either GCC toolchain.

I'm not sure what this means. It at least seems to be a consistent problem but whether it's with Eclipse/CDT or the specific PC is beyond me.

Again, any suggestions would be much appreciated.

[jonahgraham]

Thank you @jarsudsco for taking the time to report this issue. I understand it takes some time and effort to make such reports and the whole community surely appreciates the time it took.

[jarsudsco]

Further:

Suspecting it might be a problem on my machine, as well as the fresh install of 2023-03 I also did fresh installs of 2022-12, 2022-09 and 2022-06 (the version that "works" on my old laptop). I also installed MinGW64 and tried each version of Eclipse with each version of MinGW in the system path. Looking just at the preference pages for "Core Build Toolchains" and "New C/C++ Project Wizard" I get the following results:

I changed nothing other than the system path between tests so it does look like something about 2023-03 is different...?

If I have time I'll try creating a project with each configuration. Unless the problem gets resolved of course :-)

[jonahgraham]

I think I have reproduced this. I'll link an issue here when I have more details. Thank you for the derailed info so far.

[jarsudsco]

Many thanks Jonah, if I can be of any assistance just let me know.

[jonahgraham]

This is a regression introduced in #243. I have started tracking it in #330

[jonahgraham]

There is a workaround added here until we can roll out a fix: #330 (comment)

[jarsudsco]

Many thanks Jonah, the workaround has resolved my problems, though I did initially misunderstand your description of the workaround so in case it's helpful to anyone else...

I initially added a DisplayName value to the "Uninstall" key itself but when that didn't work I realised all the keys under "Uninstall" already had DisplayName values except the one shown above - "InstallShield Uninstall Information", adding a DisplayName to this key did the job.

[jonahgraham]

The fix is now deployed. Please run Check for Updates and CDT should update to CDT 11.1.1 which contains the fix.

[jonahgraham]

This is a regression introduced in #243. I have started tracking it in #330 and the fix has now been deployed as CDT 11.1.1.