The {@inheritDoc} annotation is intended to tell an API generator like phpDocumentor to grab the closest parent's documentation, including interfaces. This saves time for a developer but is an issue because with any typical editor {@inheritDoc} says nothing about the class, method, or property being documented. It tells a developer to check the class declaration and see what documentation is actually supposed to be there. This means that the chain must be travelled until there is a documentation block that does NOT have ONLY a {@inheritDoc} annotation. An easy example: <?php /** * This is an interface. */ interface MyInterface { } /** * {@inheritDoc} */ class Impl implements MyInterface { } The {@inheritDoc} indicates, go up the chain and find the documentation and use that. This is recursive. That is, the parent's parent must be checked too if it exists. A more complicated example (which probably has no exact answer yet as to what it should generate): <?php /** * This is an interface. */ interface MyInterface { } /** * This class does X. */ class A { } /** * {@inheritDoc} */ class Impl extends A implements MyInterface { } The question here is whether or not to use `MyInterface` for documentation or to take class A's or to merge them (what if class A has {@inheritDoc} on methods?). It would not be that unusual to merge them, and have expandable text blocks in the hover over. Same for methods. You get from the above upon hovering over Impl (whether here or in another place like extended class): This class does X. + MyInterface: This is an interface... The extended class should take precedence especially since arguments may have been added on top of the other extended class (or implemented interface) and in PHP you can only add arguments, not remove. Finally there's the case of documentation blocks that have {@inheritDoc} but also expand. class A { /** * Plain description. * * @param boolean $asString As string. * * @return string|array Array of items or string representation if `$asString` is `true`. */ public function getSomething($asString = false) { } } class B extends A { /** * A description for this method. * * {@inheritDoc} */ public function getSomething($asStr = false) { } } Does B's explantation get used instead of A's or do they get merged with B taking precedence. Also what about the change to the argument name on B (can the parent documentation block get 'fixed' automatically here)? Does a @param tag replace A#getSomething()'s @param tag? Same for @return? There are a myriad of issues to resolve but the basic functionality is not there yet. Like it says in the title, the annotation should be processed without care for casing. Reproducible: Always Steps to Reproduce: 1. Open new PHP project. Input in file: <?php class A { /** * Plain description. * * @param boolean $asString As string. * * @return string|array Array of items or string representation if `$asString` is `true`. */ public function getSomething($asString = false) { } } class B extends A { /** * A description for this method. * * {@inheritDoc} */ public function getSomething($asStr = false) { } } 2. Hover over getSomething() in class B. Actual Results: A's documentation does not go where the {@inheritDoc} is. Expected Results: {@inheritDoc} should be replaced with class A's documentation.
Thank you for the bug report. Unfortunately we were not able to get to it yet. Can we ask you to please check if this is still an issue with KDevelop 25.12.2.