New compiler line type: cltInfo

[rickg22]

I just discovered a wonderful feature in C::B. It's called "Begin word" search :-P

With it i could finally add the compiler line type "cltInfo" so no info lines will count as warnings. I uploaded a PATCH to berlios.

The reason I didn't commit, is that the compiler, being a critical part of C::B, cannot afford unrevised commits. However, I did test the patch (I compiled C::B, and had to rebuild the entire project around 3 times to make sure it worked properly) and it works wonders.

I added a new info line: "In member function .....:" so that those STL errors can be understood more clearly.

Mind checking it out, everyone??

http://developer.berlios.de/patch/?func=detailpatch&patch_id=2057&group_id=5358

Another thing that worries me, is that saved custom compiler regexes will be altered by the addition of this new line type. I hope it's a marginal case, since not all beta testers will mess up with the compiler parsing... i hope :| - and this is another reason why I didn't commit.

Yiannis, your stance?

[MortenMacFly]

With it i could finally add the compiler line type "cltInfo" so no info lines will count as warnings.

Nice Rick! In r4094 I asked myself the question: Why do we actually don't have a cltInfo? A few days later you come up with a patch... I'm shivering... ;-) Anyways - I'm currently compiling C::B with that one incorporated. Thanks!
With regards, Morten.

Edit: First thing I noticed: The changes you made for CompilerMinGW are missing in CompilerGNUARM and CompilerGNUAVR (these are also GNU GCC based) - I'll remember that if we decide to commit the changes.
In addition I realised that in GNUARM the "Instantiated from here" line (as it is currently) has the resource compiler error twice... looks like a copy & paste error (a forgotten linefeed in that line).

[rickg22]

Actually there should NOT be an "instantiated from here" regex. Just "instantiated from" because i've gotten errors which mention a class and not just "here". This has to be corrected for all compiler sets.

BTW, here's a small snapshot of a compilation result (not build log, but build MESSAGES) after the patch.

:: === Code::Blocks, sdk ===
G:\MinGw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\include\c++\3.4.5\bits\stl_list.h:: In constructor `InfoWindow::InfoWindow(const wxString&, const wxString&, unsigned int, unsigned int)':
G:\MinGw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\include\c++\3.4.5\bits\stl_list.h:435: warning: '__p' might be used uninitialized in this function
G:\MinGw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\include\c++\3.4.5\bits\stl_list.h:: In constructor `InfoWindow::InfoWindow(const wxString&, const wxString&, unsigned int, unsigned int)':
G:\MinGw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\include\c++\3.4.5\bits\stl_list.h:435: warning: '__p' might be used uninitialized in this function
:: === Build finished: 0 errors, 2 warnings ===

See? Just 2 warnings, and now we get more info

[MortenMacFly]

Actually there should NOT be an "instantiated from here" regex.

It wasn't - don't worry, that was a typo in my post. Hence I have added the same support for the other two GCC compilers in the same style. After testing the patch for the last couple of days I don't see any negative side effects. It looks really nice to have info separated from warnings in the log. So I wouldn't have any objections from my point of view... what about the others testing this?!
With regards, Morten.

[rickg22]

the only problem would arise (I think) with people with custom compilers, upgrading from previous installations of Code::Blocks. They'd have to change their compilers, which is why I'm unsure of making this change into the trunk. Perhaps we should add a new popup message (InfoWindow)?

[MortenMacFly]

the only problem would arise (I think) with people with custom compilers, [...]

I am such (I have quite some custom additional "native" and copy-based compilers) but I don't really see a big issue. Isn't the only thing that can happen that people still see warnings, where information maybe better... so what?! I guess I'm missing something...?!
With regards, Morten.

[rickg22]

Let's see what Don Corleone says 

[mandrav]

Let's see what Don Corleone says 

// version of compiler settings
// when this is different from what is saved in the config, a message appears
// to the user saying that default settings have changed and asks him if he wants to
// use his own settings or the new defaults
const wxString CompilerSettingsVersion = _T("0.0.1");

Just make the change (if it doesn't break anything else) and pump that number a bit.

[rickg22]

Thanks! That's what I was looking for. I'll commit asap.

Update: DONE! :-)

[killerbot]

everybody take care, I think a serious issue might be introduced here !!

When you have a look at default.conf, you will see that the regexes for parsing errors/warnings all are of a certain type.
Example : Compiler warning of dmd, is of type int="1" (actually on the 2 systems I checked it was at 2, old bug ).
Now this 1 resembles something :

enum CompilerLineType
{
    cltNormal,
    cltWarning,
    cltError
};

But because the enum has been INCORRECTLY changed to :

enum CompilerLineType
{
    cltNormal,
    cltInfo,
    cltWarning,
    cltError
};

That means the warning regex is now threated as of type info, and so will the error be threated as warning ...

Never ever insert values in an enum that is exported as an int !!!!!!!!!

Gonna boot up my laptop and adjust this, the cltInfo should be the last one !!!
And even then I am not sure if all compilers will correctly adjust

[mandrav]

Never ever insert values in an enum that is exported as an int !!!!!!!!!

Gonna boot up my laptop and adjust this, the cltInfo should be the last one !!!
And even then I am not sure if all compilers will correctly adjust

Nice catch killerbot .
Initialize cltNormal to 0 too, so we have predefined numbers...

[MortenMacFly]

everybody take care, I think a serious issue might be introduced here !!
Never ever insert values in an enum that is exported as an int !!!!!!!!!

I thought that's why the compiler version was changed -> thus the settings are reset and refreshed... isn't that why Rick was asking for it?! I mean: It really works on my PC, I see the correct colouring for each type even with the enum as it is now. In the end this compiler RegEx settings use the enum, right...?! (What am I missing to understand?!)
With regards, Morten.

[mandrav]

everybody take care, I think a serious issue might be introduced here !!
Never ever insert values in an enum that is exported as an int !!!!!!!!!

I thought that's why the compiler version was changed -> thus the settings are reset and refreshed... isn't that why Rick was asking for it?! I mean: It really works on my PC, I see the correct colouring for each type even with the enum as it is now. In the end this compiler RegEx settings use the enum, right...?! (What am I missing to understand?!)
With regards, Morten.

The problem is if the user decides NOT to use the new settings. His old settings will be wrong then...

[MortenMacFly]

The problem is if the user decides NOT to use the new settings. His old settings will be wrong then...

Oh yes... stupid me... that's an issue, in fact... :oops:

[rickg22]

Initialize cltNormal to 0 too, so we have predefined numbers...

You mean it's initialized to ONE???  :shock:

Ok, I'll update it and pump up the version (again) to 0.0.3. Just a last question. Should cltInfo be the second, or the last? Because in other files i assummed that cltWarning will always be greater than cltInfo.