I'm doing this year Advent of Code with U++ (built from source from github 1.12. so beta-testing it), posting my solutions at github (spoilers alert, if you want to try AoC yourself).

So far everything seems to work for me quite well, I have seen only minor issues.

One very minor issue is strange temporary "freeze" of IDE after closing the terminal with finished run of code in certain situations, the detailed setup:
OS: KDE Neon (KDE5 developer's distribution based on Ubuntu 22.04 LTS with KDE desktop)
IDE config - Console binary: /usr/bin/konsole -e
project: U++ Core CLI, using Cout() to display output.
- when I run the project Ctrl+F5, it opens new terminal, outputs results, the terminal shows "<--- Finished, press [ENTER] to close the window --->"
- then I use mouse to select something from the output, Ctrl+Shift+C to copy it to clipboard, press enter to close the terminal
- the terminal does close (so far all of this is OK), but TheIDE is frozen for 5-10 seconds, not showing cursor, or reacting to clicks, etc..
- then it starts reacting again

It may be also some issue with KDE and clipboard thing, as did notice the OS clipboard sometimes losing content when I close the app from which the content was copied, but in this case it seems the text from Konsole survives, just IDE is stuck on something.

Other minor issue is syntax highlight of C++ numeric literals, I think Mirek did implement the apostrophe digit separator few years back, but now it looks like it does think some char string starts there, see attached image.

Hi Mirek,

Please start typing a floating point constant (e.g. 1.) .. and the code completion starts to look for something to add after the point. Can this behavior be removed?

Best regards,

Tom

Code formatting is not working (properly). Just formatting <CtrlCore/CtrlCore.h> for a demonstration. All bitfield's are formatted in a strange, unpleasant way. And there are more problems than that. After all, the code is quite old.

In the same spirit that U++ embraces libclang, it
's desirable to move code formatting to utilize LibFormat (part of the llvm-project). It should be quite easy for Mirek with his experience integrating libclang.

ok. We don't really need that much flexibility as offered by LibFormat; just formatting code to u++ preferred style is satisfactory. This way code will look more consistent. The AStyle utility that's currently used is very broken

Lance wrote on Sun, 11 December 2022 21:13

ok. We don't really need that much flexibility as offered by LibFormat; just formatting code to u++ preferred style is satisfactory. This way code will look more consistent. The AStyle utility that's currently used is very broken

I can remove it completely for 2022.2, but not replace...

Hello Mirek and Lance,

I think we should remove AStyle completely from the TheIDE. The true thing is that there is no true maintainer of that code and it was not updated for years. However, I think we should do it when we will have alternative.

As a replacement to AStyle we should go with clang-format executable. It is bundle with clang tool-chain.

I have found an interesting bug.
The new assist complained about a lot of weird bugs in my code.
I'm using some external libraries, so I created a new .bm file and used it for compiling.
But it seemed to me, that Assist isn't working based on that .bm file, so I removed all the other .bm files, and renamed my custom one to CLANG.bm.
Everything seems to be working well now.

Currently it is always using include paths from CLANG.bm method. There does not seem an easy solution unfortunately as other includes can be incompatible. But I guess adding include paths from current build method at the end of the list should work (will do ASAP).

I have found an interesting bug.
The new assist complained about a lot of weird bugs in my code.
I'm using some external libraries, so I created a new .bm file and used it for compiling.
But it seemed to me, that Assist isn't working based on that .bm file, so I removed all the other .bm files, and renamed my custom one to CLANG.bm.
Everything seems to be working well now.

mirek wrote on Sun, 11 December 2022 16:54

Lance wrote on Sun, 11 December 2022 21:13

ok. We don't really need that much flexibility as offered by LibFormat; just formatting code to u++ preferred style is satisfactory. This way code will look more consistent. The AStyle utility that's currently used is very broken

I can remove it completely for 2022.2, but not replace...

Yes, time is too tight. It should be removed as it serves no practical purposes in its current state, other than messing up code.

Klugier wrote on Sun, 11 December 2022 23:08

Hello Mirek and Lance,

I think we should remove AStyle completely from the TheIDE. The true thing is that there is no true maintainer of that code and it was not updated for years. However, I think we should do it when we will have alternative.

As a replacement to AStyle we should go with clang-format executable. It is bundle with clang tool-chain.

Quick check: I do not see it in toolchain we are using in Win32....

Lance wrote on Mon, 12 December 2022 00:52

mirek wrote on Sun, 11 December 2022 16:54

Lance wrote on Sun, 11 December 2022 21:13

ok. We don't really need that much flexibility as offered by LibFormat; just formatting code to u++ preferred style is satisfactory. This way code will look more consistent. The AStyle utility that's currently used is very broken

I can remove it completely for 2022.2, but not replace...

Yes, time is too tight. It should be removed as it serves no practical purposes in its current state, other than messing up code.

AStyle removed.

Hi,

It seems StaticText has changed. Where is:

StaticText::GetFont();

Or how can I get this done now?

Best regards,

Tom

Mirek,

Thanks, it works now. (Also thanks for fixing the warnings with MSBTx64.)

Just noticed that the left stripe in code editor no longer shows errors, just recently edited code. (I'm on Windows if that has any significance...)

Best regards,

Tom

OK, I see. I turned back on the 'Show errors in the current file...' option. It seems less intrusive now. Maybe I will learn to like it.

Unfortunately, it seems to erroneously flag my structure packing pragma:

#pragma pack(push,1)

It complains about "Unterminated #pragma pack(push,...) at end of file". It seems to ignore:

#pragma pack(pop)

following the packed structure(s).

Best regards,

Tom

OK, I see. I turned back on the 'Show errors in the current file...' option. It seems less intrusive now. Maybe I will learn to like it.

Unfortunately, it seems to erroneously flag my structure packing pragma:

#pragma pack(push,1)

It complains about "Unterminated #pragma pack(push,...) at end of file". It seems to ignore:

#pragma pack(pop)

following the packed structure(s).

Best regards,

Tom

OK, I see. I turned back on the 'Show errors in the current file...' option. It seems less intrusive now. Maybe I will learn to like it.

Unfortunately, it seems to erroneously flag my structure packing pragma:

#pragma pack(push,1)

It complains about "Unterminated #pragma pack(push,...) at end of file". It seems to ignore:

#pragma pack(pop)

following the packed structure(s).

Best regards,

Tom

Tom1 wrote on Tue, 13 December 2022 11:42

OK, I see. I turned back on the 'Show errors in the current file...' option. It seems less intrusive now. Maybe I will learn to like it.

Unfortunately, it seems to erroneously flag my structure packing pragma:

#pragma pack(push,1)

It complains about "Unterminated #pragma pack(push,...) at end of file". It seems to ignore:

#pragma pack(pop)

following the packed structure(s).

Best regards,

Tom

-Wno-pragma-pack seems to do the job. It is now default (but you will need to add it to Assist setup. Note that unless you update theide (one more bug fixed), it needs restart).

Thanks for testing. At this time very helpful. I still want to release 2022.2 (not 2023.1)

Please note though that 2022.2 has been out for quite some time, so this must be 2022.3. (The U++ front page says 2022.2 (rev. 16270)).

BR, Tom

zsolt wrote on Mon, 12 December 2022 12:42

I have found an interesting bug.
The new assist complained about a lot of weird bugs in my code.
I'm using some external libraries, so I created a new .bm file and used it for compiling.
But it seemed to me, that Assist isn't working based on that .bm file, so I removed all the other .bm files, and renamed my custom one to CLANG.bm.
Everything seems to be working well now.

I am now adding "real" build method's include paths after CLANG's ones. Hopefully this might fix this issue...

An other bug:
Assist goes mad on .icpp files. Try opening Painter/PainterInit.icpp
It is just trying to parse it without success endlessly:

C:\Download\Upp\upp\uppsrc\Painter\PainterInit.icpp parsed in 15 ms
C:\Download\Upp\upp\uppsrc\Painter\PainterInit.icpp parser output processed in 0 ms
Failed commandline: C:\Download\Upp\upp\uppsrc\Painter\PainterInit.icpp -DflagDEBUG -DflagDEBUG_FULL -DflagMAIN -DflagCLANG  -std=c++14 -xc++ -Wno-logical-op-parentheses 
C:\Download\Upp\upp\uppsrc\Painter\PainterInit.icpp parsed in 0 ms
C:\Download\Upp\upp\uppsrc\Painter\PainterInit.icpp parser output processed in 0 ms
Failed commandline: C:\Download\Upp\upp\uppsrc\Painter\PainterInit.icpp -DflagDEBUG -DflagDEBUG_FULL -DflagMAIN -DflagCLANG  -std=c++14 -xc++ -Wno-logical-op-parentheses 

Thanks.
Sometimes Assist ended up in parsing them endlessly, so I started to rename .icpp files to .cpp.
As I can see, they are not needed anymore. I used them for registering translations and unit tests, but now they are working in .cpp files as well.

zsolt wrote on Tue, 13 December 2022 18:17

Thanks.
Sometimes Assist ended up in parsing them endlessly, so I started to rename .icpp files to .cpp.
As I can see, they are not needed anymore. I used them for registering translations and unit tests, but now they are working in .cpp files as well.

Careful here:

The purpose of .icpp was that it never went into .lib file during the build process, always are linked as .obj. This has the effect that it is always linked; files in .lib can be ignored if there are no references to its contents from other files.

In debug, theide builder does not bother creating .libs. So what you do can work in debug and fail in release.

Current U++ really dropped .icpp use (but still supports them when building), replaced with INITIALIZE and INITIALIZER macros (which basically create the reference to initializer by including the file). It is not ideal either, but makes U++ tiny bit more standard.

mirek wrote on Tue, 13 December 2022 18:32

zsolt wrote on Tue, 13 December 2022 18:17

Thanks.
Sometimes Assist ended up in parsing them endlessly, so I started to rename .icpp files to .cpp.
As I can see, they are not needed anymore. I used them for registering translations and unit tests, but now they are working in .cpp files as well.

Careful here:

The purpose of .icpp was that it never went into .lib file during the build process, always are linked as .obj. This has the effect that it is always linked; files in .lib can be ignored if there are no references to its contents from other files.

In debug, theide builder does not bother creating .libs. So what you do can work in debug and fail in release.

Current U++ really dropped .icpp use (but still supports them when building), replaced with INITIALIZE and INITIALIZER macros (which basically create the reference to initializer by including the file). It is not ideal either, but makes U++ tiny bit more standard.

Thanks, I have just checked these macros, but I think, it would be a nightmare to use them for every unit tests I created.
But I turned on Blitz for compiling release builds and it seems to me, that it doesn't generate .libs. Is that true?