Skip to content

Conversation

@tobyhede
Copy link
Contributor

No description provided.

Changed OPTIMIZE_OUTPUT_FOR_C from YES to NO in Doxyfile to enable
C++ overloading support. SQL supports function overloading (like C++),
but C does not. This setting allows Doxygen to better handle overloaded
SQL functions, though a Doxygen limitation still causes the first
overload in each group to be skipped during extraction.

Related documentation: docs/api/markdown/PARSING_NOTES.md
Fixed multiple parsing issues in Doxygen XML to Markdown conversion:

1. Operator functions: Extract operator name from brief description when
   function name is schema-only (fixes `->>`, `->` showing as `eql_v2()`)

2. See Also links: Only create links for exact signature matches, keep
   as plain text if referenced function doesn't exist (prevents
   self-referencing when overload variants are missing)

3. SQL parameters: Swap <type> and <declname> elements since Doxygen
   parses SQL backwards (SQL: name type, C++: type name)

4. Schema-qualified types: Properly combine <ref> tail and <declname>
   for full type names like `eql_v2.ore_block_u64_8_256`

Added test_xml_to_markdown.py to validate all parsing fixes.

Documented in docs/api/markdown/PARSING_NOTES.md
Changed "See Also" section to "Variants" with cleaner formatting:

1. Renamed section from "See Also" to "Variants" - more accurately
   describes function overloads and is clearer for users

2. Strip schema prefix from variant references to match function
   title format:
   - Before: `eql_v2."->"(eql_v2_encrypted, text)`
   - After: `->(eql_v2_encrypted, text)`

3. Add "(not documented)" label for missing variants instead of
   keeping raw reference text

Updated tests to reflect new terminology and behavior.
Copy link
Contributor

@yujiyokoo yujiyokoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I am not super-familiar with this or Python but looks good, and it's probably a good idea to check the actual output after merging rather than just the code.

@tobyhede
Copy link
Contributor Author

@yujiyokoo Good call on testing the actual output - was manually generated and inspected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants