Idea-php-symfony2-plugin: Wrong hints in services.yml, for services with a parent

[amici]

What steps will reproduce the problem?

1. Define a parent class
2. Define a child class (extend the parent one)
3. Define both classes as services, while the child is declared with "parent" keyword, so that is uses the service definition of the parent.
4. In the child service, define some additional arguments (that don't exist in parent service)

What is the expected result?
As I add new arguments for the child service, I'd expect to see the matching argument hints in editor. So, properly matched hint for 1st, 2nd or any argument.

What happens instead?
The argument hints shown for child service show the hints for the parent service instead.

Example shown below:

ParentService class:

namespace AppBundle\Services;


use Symfony\Component\Routing\Router;

class ParentService
{

    /** @var Router */
    protected $router;

    /**
     * ParentService constructor.
     * @param Router $router
     */
    public function __construct(Router $router)
    {
        $this->router = $router;
    }


}

ChildService class:

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Routing\Router;

class ChildService extends ParentService
{
    /** @var Request */
    protected $newarg;

    /**
     * ChildService constructor.
     * @param Router $router
     * @param Request $newarg
     */
    public function __construct(Router $router, Request $newarg)
    {
        $this->newarg = $newarg;
    }
}

The attached image shows the hints shown in PhpStorm, after those two classes are made.

Thanks!

[chrisaligent]

Just came across this issue myself and it caused a lot of confusion until I tracked down the cause. Our choice now is to either ignore the prominent warnings and hints, or use an alternative method of adding new arguments (possibly via a long list of setter methods):

[smilesrg]

+1 for this issue

[atakajlo]

Faced same issue. Any updates?

[nberces]

+1 for this issue

[chrisaligent]

I've stopped overriding the constructors for services with a parent, so if I need to add a new dependency I just use a setter method.
eg:

services:
    aligent.product.processor.custom:
        parent: oro.product.processor.core
        calls:
         - ['setProductRepository', ['@oro_product.repository.product']]

<?php
class AligentCustomProductProcessor extends OroProductProcessor {
    protected $productRepository;

    // NOTE: No constructor override needed

    // Custom setter
    public function setProductRepository(ProductRepository $productRepository)
    {
        $this->productRepository = $productRepository;
    }
}

Can get messy if you're injecting a lot of new services, but does reduce a lot of the confusion caused by this specific issue, and less likely to experience breaking changes when Oro decides to add a new dependency to the constructor of the service that you extended (it's happened before, even during minor upgrades).