Skip to content

Conversation

@khushiiagrawal
Copy link

@khushiiagrawal khushiiagrawal commented Jan 1, 2026

Summary

Fixes two issues with inheritance documentation:

  1. Uses Sphinx RST syntax :py:class:BaseClass`` instead of plain text for inheritance links
  2. Groups inherited methods separately and adds "Inherited from :py:class:BaseClass." notation

Fixes #180

Changes

  • CodeGenerator.py: Generate Sphinx RST syntax in class docstrings; group inherited methods after class-defined methods
  • PXDParser.py: Track inherited methods with base class names
  • DeclResolver.py: Pass base class name when attaching inherited methods
  • test_full_library.py: Update expected docstring length (93→101 chars)

Testing

  • All existing tests pass
  • Verified Sphinx RST syntax appears in class docstrings
  • Verified inherited methods are grouped after class-defined methods
  • Verified "Inherited from" notation appears in .pyi file docstrings

Test case: Bklass inheriting from A_second - inherits callA2() method

Summary by CodeRabbit

Release Notes

  • New Features

    • Inherited method documentation now includes Sphinx-style class references
    • Bounds checking applied to integral-type array access operations
    • Methods are organized separately by origin (class-defined vs inherited)
  • Improvements

    • Enhanced tracking of method inheritance context in generated code
  • Tests

    • Updated test expectations for new documentation format

✏️ Tip: You can customize this high-level summary in your review settings.

Signed-off-by: Khushi Agrawal <149886195+khushiiagrawal@users.noreply.github.com>
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 1, 2026

📝 Walkthrough

Walkthrough

The changes introduce inheritance-aware documentation generation and method tracking throughout the code generator pipeline. Inherited classes now display Sphinx-style :py:class: links in docstrings. Methods are tracked by their source (class-defined vs. inherited), with inheritance context threaded through the public API. A new integral-type detection helper refines bounds-checking logic for index operations.

Changes

Cohort / File(s) Summary
Inheritance context threading
autowrap/CodeGenerator.py
Method signatures expanded to accept inherited_from parameter; updated _create_overloaded_method_decl, create_wrapper_for_method, create_wrapper_for_nonoverloaded_method, and _create_fun_decl_and_input_conversion to propagate inheritance metadata to documentation and stub generation.
Inheritance-aware documentation generation
autowrap/CodeGenerator.py
Class docstring generation now accepts wrap-inherits as list or single string, constructs Sphinx RST :py:class: links, and appends consolidated "Inherits from" line. Methods separated into class-defined (alphabetically) and inherited (alphabetically) cohorts with inherited\_from annotations.
Integral type detection and bounds checking
autowrap/CodeGenerator.py
Added _is_integral_type() helper method to determine integral base types. getitem/setitem wrapper logic enhanced to gate bounds checks only for integral index types; setitem retains optional upper-bound constraints.
Base class attachment with context
autowrap/DeclResolver.py
Updated _add_inherited_methods to pass base_class_name=super_cld.name when calling attach_base_methods, augmenting method attachment with originating base class context.
Inherited method tracking
autowrap/PXDParser.py
Added inherited_method_bases attribute to CppClassDecl to record the base class source for each inherited method. Extended attach_base_methods signature to accept optional base_class_name parameter and populate inheritance tracking mapping.
Test assertion update
tests/test_full_library.py
Updated expected docstring length from 93 to 101 characters due to Sphinx RST syntax expansion (:py:class: links replacing plain class names); added explanatory comment.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Poem

🐰 Inheritance now shines with links so bright,
Methods grouped and sorted just right,
From base to derived, the context flows,
Sphinx docs bloom where each method grows!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 30.77% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly summarizes the main change: fixing inheritance documentation with Sphinx RST syntax and reorganizing method grouping.
Linked Issues check ✅ Passed The code changes fully address issue #180 objectives: Sphinx RST syntax (:py:class:) replaces plain-text links, inherited methods are grouped separately with 'Inherited from' annotations, and both runtime wrappers and type stubs include the inheritance metadata.
Out of Scope Changes check ✅ Passed All changes are directly aligned with issue #180 requirements. The addition of _is_integral_type helper for bounds checking in getitem/setitem is a supporting enhancement that enables proper type-aware wrapper generation for inherited methods.
✨ Finishing touches
  • 📝 Generate docstrings

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0410f82 and d492ada.

📒 Files selected for processing (4)
  • autowrap/CodeGenerator.py
  • autowrap/DeclResolver.py
  • autowrap/PXDParser.py
  • tests/test_full_library.py
🧰 Additional context used
🧬 Code graph analysis (3)
autowrap/DeclResolver.py (1)
autowrap/PXDParser.py (1)
  • attach_base_methods (497-505)
tests/test_full_library.py (1)
tests/test_files/full_lib/B.hpp (2)
  • Bklass (20-20)
  • Bklass (21-21)
autowrap/CodeGenerator.py (2)
autowrap/ConversionProvider.py (1)
  • get (3606-3621)
autowrap/Code.py (1)
  • add (56-75)
🪛 Ruff (0.14.10)
autowrap/PXDParser.py

498-498: Loop control variable name not used within loop body

Rename unused name to _name

(B007)

🔇 Additional comments (12)
autowrap/PXDParser.py (2)

414-415: LGTM! Inheritance tracking attribute added.

The new inherited_method_bases dictionary properly tracks the source base class for each inherited method.


497-505: LGTM! Base class tracking properly implemented.

The optional base_class_name parameter correctly records the originating base class for inherited methods. The "first base wins" strategy (line 504) is appropriate for scenarios where a method might be inherited from multiple bases.

Note: The static analysis warning about unused loop variable name at line 498 is a false positive—the variable is used in lines 501, 504, and 505.

autowrap/DeclResolver.py (1)

454-454: LGTM! Base class context properly propagated.

The call correctly passes super_cld.name to track which base class is contributing inherited methods.

autowrap/CodeGenerator.py (8)

570-579: LGTM! Sphinx RST syntax correctly implemented.

The code properly generates :py:class: links for inherited base classes and handles template syntax correctly.

Minor note: The "-- Inherits from" prefix uses -- which is less common in docstrings. Consider using just spaces for indentation if this is meant to be a standard docstring line.


799-833: LGTM! Method grouping properly implemented.

The code correctly separates class-defined methods from inherited methods, generating them in order (constructor → class methods → inherited methods) with each group sorted alphabetically. The inherited_from context is properly threaded through for inherited methods.


916-916: LGTM! Inherited context added to overloaded method documentation.

The inherited_from parameter is properly added with a sensible default, and the "Inherited from" notation is correctly appended to the docstring for type stubs.

Also applies to: 990-991


1040-1040: LGTM! Parameter threading is consistent.

The inherited_from parameter is properly added to the method signature and correctly forwarded to both overloaded and non-overloaded method creation paths.

Also applies to: 1139-1139, 1159-1159


1164-1164: LGTM! Type stub documentation enhanced with inheritance context.

The inherited_from parameter is correctly added and the "Inherited from" notation is appropriately added to stub docstrings for better documentation in .pyi files.

Also applies to: 1219-1221


1396-1396: LGTM! Parameter correctly threaded through non-overloaded method wrapper.

The inherited_from parameter is properly added and forwarded to complete the inheritance context propagation chain.

Also applies to: 1405-1405


1727-1733: LGTM! Integral type detection helper added.

The _is_integral_type method correctly identifies integer-like types suitable for bounds checking. The set of types is comprehensive and appropriate for typical indexing scenarios.


1752-1752: LGTM! Bounds checking correctly gated by integral type detection.

The _is_integral_type check appropriately gates bounds checking to only integer-like indices, preventing incorrect checks on non-integral types like string keys.

Also applies to: 1755-1755, 1849-1849, 1852-1852, 1860-1860

tests/test_full_library.py (1)

286-287: Verify the expected docstring length value of 101.

The comment's arithmetic is incorrect: 93 + 12 = 105, not 101. Based on tracing the code generator logic (CodeGenerator.py lines 568-584), the docstring components are:

  • "Cython implementation of Bklass\n" (32 chars)
  • " -- Inherits from :py:class:A_second\n" (44 chars)
  • "\n some doc!" (14 chars)

This totals 90 characters, not 101. Verify that 101 is the correct expected value for the test, as either the test value or the comment explanation (or both) appears to be incorrect.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@khushiiagrawal
Copy link
Author

@jpfeuffer Please take a look.
Thanks!

@jpfeuffer
Copy link
Contributor

Looks good but to be sure, we would need to see a sphinx documentation page with autodoc for this.

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.

Adapt docstring generation regarding inheritance

2 participants