New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increasing access of inherited C++ members with 'using...' is not recognized by Doxygen (Origin: bugzilla #789168) #6277

Open
doxygen opened this Issue Jul 2, 2018 · 0 comments

Comments

Projects
None yet
1 participant
@doxygen
Owner

doxygen commented Jul 2, 2018

status REOPENED severity normal in component general for ---
Reported in version 1.8.13 on platform Other
Assigned to: Dimitri van Heesch

On 2017-10-18 17:45:33 +0000, the.crazed.cat.herder@gmail.com wrote:

Consider the following C++ code:

class BaseClass
{
public:

	BaseClass() { };
	virtual ~BaseClass() {};

protected:

	void SomeFunc() {};

};


class DerivedClass1 : public BaseClass
{
public:

	DerivedClass1() {};
	virtual ~DerivedClass1() {};

	using BaseClass::SomeFunc;

};


class DerivedClass2 : protected BaseClass
{
public:

	DerivedClass2() {};
	virtual ~DerivedClass2() {};

	using BaseClass::SomeFunc;

};

In both these sample derived classes, BaseClass::SomeFunc has had it's access changed to 'public' by employing the keyword 'using'. This is true regardless of the base class access level (public in DerivedClass1, protected in DerivedClass2), and regardless of the member access level originally defined in BaseClass (protected, in this example.)

Unfortunately, Doxygen insists that SomeFunc is still protected in both example derived classes. This is incorrect - employing 'using' in this manner to increase the access of the inherited BaseClass::SomeFunc is perfectly valid C++ (as of C++11, I believe), and VC++ recognizes this; it is, in fact, publicly accessible in both derived classes.

See http://en.cppreference.com/w/cpp/language/using_declaration for more information.

On 2017-10-29 10:48:09 +0000, Dimitri van Heesch wrote:

Confirmed. Should be fixed in the next GIT update.

On 2017-10-31 01:29:06 +0000, the.crazed.cat.herder@gmail.com wrote:

Thanks very much!

Soo... errr.... I don't suppose I could convince you to release an updated set of Windows binaries....?

:)

On 2017-11-19 12:09:39 +0000, Vladimír Vondruš wrote:

Hi,

was not sure what's the proper place where to report this, so I'm commenting here. 

The change at https://github.com/doxygen/doxygen/commit/SHA: 9468ede259153cf79eb8d61635389744e9a2ee7d that aims to fix this bug broke XML output for me on classes that move public overloaded member to private section. Here's a minimal repro case:

    /** @brief Foo */
    struct Foo {
        /** @brief Do a thing */
        void thing();

        /** @brief Do a thing with int */
        void thing(int);
    };

    /** @brief Bar */
    struct Bar: Foo {
        private: using Foo::thing;
    };

And here's a minimal Doxyfile:

    INPUT                  = class.h
    QUIET                  = YES
    GENERATE_HTML          = NO
    GENERATE_LATEX         = NO
    GENERATE_XML           = YES

For me, Doxygen crashes when producing the XML output, leaving half-written or empty XML files. Doesn't happen when generating just the HTML or LaTeX output; doesn't happen when making private things public, doesn't happen when there's just one non-overloaded function. Reverting the above commit makes everything working again.

Hope this is enough info. Thank you for looking into this.

On 2017-11-19 14:23:25 +0000, Dimitri van Heesch wrote:

Thanks for the report. I've made this commit to avoid the crash:

https://github.com/doxygen/doxygen/commit/SHA: 1a1fdbed64de6ce01959b2e4d0988be823fb6bad

Let me know if works for you.

On 2017-11-19 14:42:19 +0000, Vladimír Vondruš wrote:

Yes, this works for me. Thanks for the fast reaction!

On 2017-12-25 18:44:02 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.8.14. Please verify if this is indeed the case. Reopen the
bug if you think it is not fixed and please include any additional information 
that you think can be relevant (preferably in the form of a self-contained example).

On 2017-12-27 22:09:53 +0000, the.crazed.cat.herder@gmail.com wrote:

Hi, Dimitri -

The fix works for the case I gave as an example, but seems to be failing on a more complex case from the same source code library. I'm currently trying to distill it to as simple an example as possible. Would it be appropriate to continue here, or should I open a new bug report? As I say, the fix DOES work for the original code sample.

And thanks for your work.

On 2017-12-29 18:26:38 +0000, the.crazed.cat.herder@gmail.com wrote:

Hi, Dimitri -

Consider the following example:


class BaseClass
{
public:

	BaseClass() { };
	virtual ~BaseClass() {};

	void SomePublicFunc() {};

protected:

	void SomeProtectedFunc() {};

};


class FirstGenDescendant : public BaseClass
{
public:

	FirstGenDescendant() {};
	virtual ~FirstGenDescendant() {};

	using BaseClass::SomeProtectedFunc;

};


class SecondGenDescendant : protected FirstGenDescendant
{
public:

	SecondGenDescendant() {};
	virtual ~SecondGenDescendant() {};

	using FirstGenDescendant::SomePublicFunc;
	using FirstGenDescendant::SomeProtectedFunc;


};

Ver. 1.8.14 treats the first descendant class properly - SomProtectedFunc gets listed as public. But the protected class inheritance in SecondGenDescendant seems to break things - SomePublicFunc and SomeProtectedFunc should both be listed as public in SecondGenDescendant, by dint of the 'using' declarations.

(And FWIW, the latest version of Visual Studio's Intellisense also gags on this. The compiler treats it properly, but Intellisense and ClassView both get it wrong. So you aren't alone.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment