Page MenuHomeFreeBSD

Private inheritance hides base-class names.
AbandonedPublic

Authored by adridg on Oct 12 2019, 6:41 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 Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 27007
Build 25300: arc lint + arc unit

Event Timeline

adridg created this revision.Oct 12 2019, 6:41 PM

(This should have gone to the KDE Phab instead)

Thomas.Eschenbacher_gmx.de requested changes to this revision.Fri, Oct 18, 4:04 AM

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.Fri, Oct 18, 4:04 AM
adridg abandoned this revision.Sun, Oct 20, 6:12 PM

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