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?