Doxygen: C++: Trailing return type syntax + void

[pJunger]

Hi,

I noticed that function definitions that use the C++11 trailing return syntax with void
produce warnings:
return type of member side_effect is not documented

Example:

/*!
 * \brief Performs some side effect
 */
auto side_effect() -> void {}

[louis-langholtz]

Possibly related to issue #5492.

[albert-github]

@louis-langholtz as far as I can see the issue #5492 is a different type of issue.

I've just pushed a proposed patch, pull request #8014 for the issue reported here.

[louis-langholtz]

@louis-langholtz as far as I can see the issue #5492 is a different type of issue.

I've just pushed a proposed patch, pull request #8014 for the issue reported here.

I'm glad to see this activity! Will the pushed code help improve Doxygen seemingly messing up on parsing of trailing return types in general or just for a trailing return type of void?

In any case, I found both this issue and the one I linked when trying to figure out why Doxygen was seemingly inconsistently messing up with some templated code of mine which compiles fine but uses trailing return types. I know Doxygen isn't supposed to be a full fledged C++ parser but I'd really like it to work better with that code.

Here's a sample of that code where Doxygen seems to start messing up:

/// @brief Constrained value stream output operator for value types which support it.
/// @tparam ValueType Type of the value used by the checked value.
/// @tparam CheckerType Type of the checker used by the checked value.
/// @relatedalso CheckedValue
template <typename ValueType, typename CheckerType>
auto operator<<(::std::ostream& os, const CheckedValue<ValueType, CheckerType>& value) ->
    decltype(os << ValueType{value})
{
    return os << ValueType{value};
}

The resulting HTML shows the trailing return type sans the enclosing parenthesis as in -> decltype(os << ValueType.

In another instance with the following code then of:

/// @brief Constrained value equality operator or value types which support it.
/// @tparam LhsValueType Type of the value used by the left hand side checked value.
/// @tparam LhsCheckerType Type of the checker used by the left hand side checked value.
/// @tparam RhsValueType Type of the value used by the right hand side checked value.
/// @tparam RhsCheckerType Type of the checker used by the right hand side checked value.
/// @relatedalso CheckedValue
template <typename LhsValueType, typename LhsCheckerType, typename RhsValueType, typename RhsCheckerType>
constexpr auto operator== (const CheckedValue<LhsValueType, LhsCheckerType>& lhs,
                           const CheckedValue<RhsValueType, RhsCheckerType>& rhs)
    noexcept(noexcept(std::declval<LhsValueType>() == std::declval<RhsValueType>()))
-> decltype(LhsValueType{lhs} == RhsValueType{rhs})
{
    return LhsValueType{lhs} == RhsValueType{rhs};
}

I get the following documentation from Doxygen that also has an incomplete Initial value code snippet in it:

[albert-github]

@louis-langholtz thanks for the case.
The problem here the { in the return type, which is currently seen as the start of the body and is a different problem from the problem reported in this issue.

To keep the issues a bit clean can you please create a new issue for this problem?
What do you mean exactly by "has an incomplete Initial value code snippet in it", is it just the part {lhs.... that is missing?

The proposed pull request for this issue (#6442) has only influence on the warning regarding the return type.

[louis-langholtz]

The problem here the { in the return type, which is currently seen as the start of the body and is a different problem from the problem reported in this issue...

I just tried changing the syntax of my trailing return types from using brackets to using parenthesis - i.e. changed code like decltype(os << ValueType{value}) to decltype(os << ValueType(value)). Doxygen is now providing much more preferable and reliable results.

Thank you so much for recognizing this problem!

I've created a new issue (issue #8017 ) to address handling of this per your request. Thanks again!!

[albert-github]

For the original problem: Code has been integrated in master on github (please don't close the issue as this will be done at the moment of an official release).

Note: the second problem as now reported by #8017 has already been fixed and integrated in master on github.

[doxygen]

This issue was previously marked 'fixed but not released',
which means it should be fixed in doxygen version 1.9.0.
Please verify if this is indeed the case. Reopen the
issue 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).