Bugzilla – Bug 78625
gcc kopete namespace issue
Last modified: 2007-06-05 12:34:32 UTC
From a mail: > > ~adrian/kopete-enable-final-gcc4.cpp > > > > the class ist "KopeteAwayDialog". > > > > Is it a gcc bug or can you easily see the error inside ? > > It's a very dumb error message, but (I believe) it is correct. The > situation is like so: So, I'm not so sure about the correctness anymore, but I need someone else (Paolo?) to clarify. I've reduced it to the below testcase: -------------------------------------- class KopeteAwayDialog { KopeteAwayDialog(); }; namespace Kopete { class Away { friend class KopeteAwayDialog; }; } using namespace Kopete; KopeteAwayDialog::KopeteAwayDialog(){} -------------------------------------- Note the 'using' directive. (In the original source it's in front of the namespace decl which contains the Away decl, but if placed after it, like above, it breaks also). Either removing the using directive or adding a global scope to the friend decl removes the error message, which is: a.cpp:16: error: ‘KopeteAwayDialo has not been declared a.cpp:16: error: ISO C++ forbids declaration of ‘KopeteAwayDialog’ with no type I don't think the using directive should have this effect, especially because in the above testcase it's placed _after_ the friend decl.
Hi Michael. I agree with your analysis and believe the snippet should compile. In fact, both Icc in strict-mode *and* current gcc mainline accept it: most likely, the below patches from Kriang in march did the trick: 2005-03-14 Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net> PR c++/4403 PR c++/9783, DR433 2005-03-14 Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net> Friend class name lookup 5/n PR c++/1016 In the face of that, I'm not sure what we want to do: we don't want our own 4_0-derived branch, right?
Why not backport it to the normal 4.0 branch? Regressions should be able to be fixed, or? Having said that, we will eventually create our own branch, but I want this to happen as late as possible, so either we would add a patch in the RPM, or this will be fixed in the 4.0 branch (preferably) and we pick it up.
> Why not backport it to the normal 4.0 branch? Regressions should be able > to be fixed, or? Ah, I didn't it was a regression! A 3.3 regression, indeed. Therefore, I will just file a PR with your reduced testcase. > Having said that, we will eventually create our own branch, but I want > this to happen as late as possible, so either we would add a patch in the > RPM, or this will be fixed in the 4.0 branch (preferably) and we pick > it up. Agreed.
Actually IMHO it would be good to fix as many bugs we see in 4.0, be they regressions or not. In this case it was easy to determine that it was a regression, as we compiled the package with 3.3 and couldn't with 4.0. But even in less clear cases I would at least try to also fix it in 4.0. It would be good for the SuSE compiler at least, and also good for the 4.0 compiler in general.
> Actually IMHO it would be good to fix as many bugs we see in 4.0, be they > regressions or not. I'm certainly in the process of doing that, for the library, at least ;)
Hi Michael: what shall we do with this internal PR in the light of the resolution of FSF c++/21235? Shall we try to convince the front-end maintainers (Mark?) to back-port the fix present in mainline, or maybe just queue that for our 4_0-based branch, or even close it and figure out a workaround (actually, the last option makes some sense, since, as I understand the issue, this specific use of friends was broken in previous releases of GCC anyway and the code is not really portable as-is to a range of recent GCCs) ??
Tough call. The problem is, that the program (kopete) was working fine before, even if GCC had wrong behaviour, so in that sense it's a regression. Kriang mentioned in PR19403 that this is technically no regression (and to some extent I agree with him), and hence no backport for 4.0. It would need to be tested if kopete as is can be compiled with 4.1, and works. If yes, then overall this is a regression. But even if not strictly a regression, I'm of the opinion that if possible the C++ parser of 4.0 should be the same as 4.1. Would you like to ask Kriang for reconsidering, or hardness of backporting, or shall I?
> But even if not strictly a regression, I'm of the opinion that if possible > the C++ parser of 4.0 should be the same as 4.1. Would you like to ask > Kriang for reconsidering, or hardness of backporting, or shall I? I can do that, no problem. Only, consider that I don't know Kriang particularly well, therefore I don't have any special influence ;) Maybe, all in all, it's better also involving Mark from the beginning (and, in any case, he has to approve the thing, eventually) I will send a message to both.
Fixed in openSUSE 10.2. And I guess also in 10.1.