After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 791942 - Redundant whitespace removal breaks some C++ links [with test case and Git bisect]
Redundant whitespace removal breaks some C++ links [with test case and Git bi...
Status: RESOLVED OBSOLETE
Product: doxygen
Classification: Other
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
[moved_to_github]
Depends on:
Blocks:
 
 
Reported: 2017-12-25 12:21 UTC by Vladimír Vondruš
Modified: 2018-07-30 10:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vladimír Vondruš 2017-12-25 12:21:34 UTC
Hello,

the following snippet produces no warning and gives the expected result in 1.8.11:

    /**
    @brief A namespace

    - Link to an UDL that works: @link operator""_op @endlink
    - Link to an UDL that doesn't: @link operator""_oq @endlink
    - Link to a function that works: @ref foo(std::initializer_list< T* >)
    - Link to a function that doesn't: @ref foo(std::initializer_list<T*>)
    */
    namespace NS {

    /** @brief An operator */
    int operator""_op(unsigned long long);

    /** @brief Another operator */
    int operator "" _oq(unsigned long long);

    /** @brief Function */
    void foo(std::initializer_list<T*>);

    }

However, after 1.8.11, the second and fourth link give a warning and no link is generated for these. I don't think the parsing should be so sensitive to whitespaces and since it worked before, I think this is a regression. I managed to bisect the change down to this commit https://github.com/doxygen/doxygen/commit/00ee930a1d73e11885197102c54fd4c8141127da and wanted to submit a PR fixing this, but I don't understand the code so well to be able to do that :/

Thank you a lot!
Comment 1 Vladimír Vondruš 2018-04-17 11:11:47 UTC
Hi,

any chance of getting this fixed? 

Found another bug related to this commit. Consider the following snippet:

    /** @brief A templated structure */
    template<class T> struct S {};

    /** @brief A templated structure specialization */
    template<class T> struct S<T*> {
        /** @brief Inner struct */
        struct SS {};
    };

With the above mentioned commit present, `struct SS` is appearing in the XML 
output as `<innerclass>` of `S`, which is not correct. If I revert the commit, 
`struct SS` is correctly appearing in the XML output as `<innerclass>` of 
`S<T*>`. This is only if the type contains a pointer or reference in the 
specialization. If I change it to for example this:

    /** @brief A templated structure specialization */
    template<class T> struct S<typename std::add_pointer<T>::type> {
        /** @brief Inner struct */
        struct SS {};
    };

which, well, compiles to the same, but is ugly, then `SS` is always considered
an `<innerclass>` of `S<typename std::add_pointer<T>::type>` independent of 
this commit being reverted or not.

Just for the record, original report that triggered this is here: 
https://github.com/mosra/m.css/issues/35

I have a project that depends on correct behavior of this and at the moment I 
have to run on a custom Doxygen version that has the above commit reverted, but
that causes other problems as some links have different hashes etc. Would be 
really great if you could have a look on this.

Thank you!
Comment 2 André Klapper 2018-07-30 10:24:54 UTC
As discussed in https://github.com/doxygen/doxygen/pull/734 , Doxygen has moved its issue tracking to 

   https://github.com/doxygen/doxygen/issues

All Doxygen tickets in GNOME Bugzilla have been migrated to Github. You can subscribe and participate in the new ticket in Github. You can find the corresponding Github ticket by searching for its Bugzilla ID (number) in Github.

Hence I am closing this GNOME Bugzilla ticket.
Please use the corresponding ticket in Github instead. Thanks a lot!