Page MenuHomeFreeBSD

Private inheritance hides base-class names.
AbandonedPublic

Authored by adridg on Oct 12 2019, 6:41 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 20 2023, 12:12 AM
Unknown Object (File)
Aug 27 2023, 7:19 PM
Unknown Object (File)
Jun 26 2023, 11:16 PM
Unknown Object (File)
Jun 16 2023, 3:21 AM
Unknown Object (File)
May 14 2023, 2:17 PM
Unknown Object (File)
May 3 2023, 2:53 AM
Unknown Object (File)
Jan 7 2023, 9:58 PM

Details

Summary

Kwave fails to compile with clang 9.0, with this kind of error message:

In file included from /wrkdirs/usr/ports/audio/kwave/work/kwave-19.08.1/libkwave/undo/UndoDeleteAction.cpp:24:
/wrkdirs/usr/ports/audio/kwave/work/kwave-19.08.1/libkwave/MultiTrackReader.h:61:24: error: 'QList' is a private member of 'QList<Kwave::SampleReader *>'

const QList<unsigned int> &track_list,
      ^

/wrkdirs/usr/ports/audio/kwave/work/kwave-19.08.1/libkwave/MultiTrackSource.h:41:36: note: constrained by private inheritance here

private QList<SOURCE *>
^~~~~~~~~~~~~~~~~~~~~~~

/usr/local/include/qt5/QtCore/qlist.h:127:7: note: member is declared here
class QList

^

1 error generated.

This can be demonstrated much more shortly with this code:

class foo {};
class bar : private foo {};
class baz : public bar
{

public:
    foo m_foo;

};

Within baz, foo is looked up in bar, and then (because it's *private*
inheritance) afterwards access-control kicks in and disallows its use.
By fully-qualifying foo (or, in Kwave's case, QList) the name-lookup
happens differently, and the public (global) name is found.

There is also a description of the problem on StackOverflow,
https://stackoverflow.com/questions/41595208/accessing-the-name-of-a-private-inherited-class-from-a-subclass

Test Plan
  • still compiles
  • packaging on FreeBSD-CURRENT, with clang 9, works again

Diff Detail

Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 27007
Build 25300: arc lint + arc unit

Event Timeline

(This should have gone to the KDE Phab instead)

sorry, but I do not understand where there should be a problem. "QList" is definitly no "private" class here, that's nonsense.
If that was a general problem, it should complain at ~1000 other places too.
Anyway... I was able to reproduce that with clan-9 and it made me reconsider using a QList as container, which is not the best choice for that purpose.
I changed my code from QList<unsigned int> to QVector<unsigned int>
(KDE git commit ae4027d640d3297e78d8d0c87389aade128476a5) and that works just fine!

That makes it hard for me to believe that this shall not be a compiler bug.

This revision now requires changes to proceed.Oct 18 2019, 4:04 AM

This should have been in KDE Phab to begin with, https://phabricator.kde.org/D24604