After upgrading to Doxygen 1.18.0, there are 2 kinds of errors:
- @ref func() for static function is broken because of parens
- @ref struct.member with anonymous struct/union is broken
Parentheses are removed from inline function references.
The second issue is more difficult and requires to degrade the doc
by providing a global link to the struct page for the fields.
The root causes of these issues can be found in these links:
https://github.com/doxygen/doxygen/commit/e1bff01
https://github.com/doxygen/doxygen/issues/12226
Cc: [email protected]
Signed-off-by: Thomas Monjalon <[email protected]>
---
lib/eventdev/rte_eventdev.h | 22 +++++++++++-----------
lib/graph/rte_graph_feature_arc.h | 8 ++++----
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
index 4e13a38d89..db730131f2 100644
--- a/lib/eventdev/rte_eventdev.h
+++ b/lib/eventdev/rte_eventdev.h
@@ -744,12 +744,12 @@ enum rte_event_dev_preschedule_type {
RTE_EVENT_PRESCHEDULE_NONE,
/**< Disable pre-schedule across the event device or on a given event
port.
* @ref rte_event_dev_config.preschedule_type
- * @ref rte_event_port_preschedule_modify()
+ * @ref rte_event_port_preschedule_modify
*/
RTE_EVENT_PRESCHEDULE,
/**< Enable pre-schedule always across the event device or a given
event port.
* @ref rte_event_dev_config.preschedule_type
- * @ref rte_event_port_preschedule_modify()
+ * @ref rte_event_port_preschedule_modify
* @see RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE
* @see RTE_EVENT_DEV_CAP_PER_PORT_PRESCHEDULE
*/
@@ -758,7 +758,7 @@ enum rte_event_dev_preschedule_type {
* Delay issuing pre-schedule until there are no forward progress
constraints with
* the held flow contexts.
* @ref rte_event_dev_config.preschedule_type
- * @ref rte_event_port_preschedule_modify()
+ * @ref rte_event_port_preschedule_modify
* @see RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE
* @see RTE_EVENT_DEV_CAP_PER_PORT_PRESCHEDULE
*/
@@ -1524,8 +1524,8 @@ struct __rte_aligned(16) rte_event_vector {
*
* NOTE:
* In restoring event order of forwarded events, the eventdev API guarantees
that
- * all events from the same flow (i.e. same @ref rte_event.flow_id,
- * @ref rte_event.priority and @ref rte_event.queue_id) will be put in the
original
+ * all events from the same flow (i.e. same @ref rte_event "flow_id",
+ * @ref rte_event "priority" and @ref rte_event "queue_id") will be put in
the original
* order before being forwarded to the destination queue.
* Some eventdevs may implement stricter ordering to achieve this aim,
* for example, restoring the order across *all* flows dequeued from the
same ORDERED
@@ -1537,8 +1537,8 @@ struct __rte_aligned(16) rte_event_vector {
#define RTE_SCHED_TYPE_ATOMIC 1
/**< Atomic scheduling
*
- * Events from an atomic flow, identified by a combination of @ref
rte_event.flow_id,
- * @ref rte_event.queue_id and @ref rte_event.priority, can be scheduled only
to a
+ * Events from an atomic flow, identified by a combination of @ref rte_event
"flow_id",
+ * @ref rte_event "queue_id" and @ref rte_event "priority", can be scheduled
only to a
* single port at a time. The port is guaranteed to have exclusive (atomic)
* access to the associated flow context, which enables the user to avoid SW
* synchronization. Atomic flows also maintain event ordering
@@ -1618,12 +1618,12 @@ struct __rte_aligned(16) rte_event_vector {
/* Event enqueue operations */
#define RTE_EVENT_OP_NEW 0
-/**< The @ref rte_event.op field must be set to this operation type to inject
a new event,
+/**< The @ref rte_event "op" field must be set to this operation type to
inject a new event,
* i.e. one not previously dequeued, into the event device, to be scheduled
* for processing.
*/
#define RTE_EVENT_OP_FORWARD 1
-/**< The application must set the @ref rte_event.op field to this operation
type to return a
+/**< The application must set the @ref rte_event "op" field to this operation
type to return a
* previously dequeued event to the event device to be scheduled for further
processing.
*
* This event *must* be enqueued to the same port that the
@@ -1631,7 +1631,7 @@ struct __rte_aligned(16) rte_event_vector {
*
* The event's fields, including (but not limited to) flow_id, scheduling type,
* destination queue, and event payload e.g. mbuf pointer, may all be updated
as
- * desired by the application, but the @ref rte_event.impl_opaque field must
+ * desired by the application, but the @ref rte_event "impl_opaque" field must
* be kept to the same value as was present when the event was dequeued.
*/
#define RTE_EVENT_OP_RELEASE 2
@@ -1659,7 +1659,7 @@ struct __rte_aligned(16) rte_event_vector {
* should be considered filled.
*
* Events with this operation type must only be enqueued to the same port that
the
- * event to be released was dequeued from. The @ref rte_event.impl_opaque
+ * event to be released was dequeued from. The @ref rte_event "impl_opaque"
* field in the release event must have the same value as that in the original
dequeued event.
*
* If a dequeued event is re-enqueued with operation type of @ref
RTE_EVENT_OP_RELEASE,
diff --git a/lib/graph/rte_graph_feature_arc.h
b/lib/graph/rte_graph_feature_arc.h
index 14f24be831..aa6495c4ad 100644
--- a/lib/graph/rte_graph_feature_arc.h
+++ b/lib/graph/rte_graph_feature_arc.h
@@ -128,7 +128,7 @@ extern "C" {
* (like VRF table for IP lookup or IPsec SA for inbound policy etc). A
* reference of allocated resource can be passed from control plane to
* dataplane via *app_cookie* argument in @ref rte_graph_feature_enable(). A
- * corresponding dataplane API @ref rte_graph_feature_data_app_cookie_get() can
+ * corresponding dataplane API @ref rte_graph_feature_data_app_cookie_get can
* be used to retrieve same cookie in fast path.
*
* When a feature is disabled, resources allocated during feature enable can be
@@ -138,9 +138,9 @@ extern "C" {
*
* If current feature node is not consuming packet, it might want to send it to
* next enabled feature. Depending upon current node is a:
- * - start_node (via @ref rte_graph_feature_data_first_feature_get())
+ * - start_node (via @ref rte_graph_feature_data_first_feature_get)
* - feature nodes added between start_node and end_node (via @ref
- * rte_graph_feature_data_next_feature_get())
+ * rte_graph_feature_data_next_feature_get)
* - end_feature_node (must not call any feature arc steering APIs) as from
* this node packet exits feature arc
*
@@ -151,7 +151,7 @@ extern "C" {
*
* rte_mbuf carries [feature_data] into feature arc specific mbuf dynamic
* field. See @ref rte_graph_feature_arc_mbuf_dynfields and @ref
- * rte_graph_feature_arc_mbuf_dynfields_get() for more details.
+ * rte_graph_feature_arc_mbuf_dynfields_get for more details.
*
* Fast path synchronization
* -------------------------
--
2.55.0
