Factor out logic that tracks mapping inheritance

[mpdude]

While working on #10396, I noticed the three kinds of mapping information track inherited and declared in the same way.

This PR suggests move the common code into a dedicated method, making it easier to see and understand where the information comes from.

[mpdude]

Would appreciate any help how to fix static analysis type hinting here

[greg0ire]

Would appreciate any help how to fix static analysis type hinting here

I've tried looking into it, and it's a nightmare. I think the right course of action would be to experiment with DTOs on 3.0.x. That would allow us to determine where to use which type hint, and whether any fields are missing in the type aliases defined at the beginning of ClassMetadataInfo… would you be willing to work on this? I think in any case, you can reset to HEAD^ and add the error you get to the baseline.

[mpdude]

I've tried looking into it, and it's a nightmare.

Probably thats because introducing a tool like Psalm into a huge legacy codebase is not fun, eh?

[mpdude]

How do I add a phpcs error to the baseline?

[greg0ire]

Probably thats because introducing a tool like Psalm into a huge legacy codebase is not fun, eh?

Yeah it's kind of a pain, thankfully there is a baseline.

[greg0ire]

How do I add a phpcs error to the baseline?

I'd rather we add Psalm issues to the baseline, so I'd make phpcs happy, then ignore Psalm.

[greg0ire]

Please squash everything into one commit that passes the build.

[mpdude]

🟢 , without updating the baseline file 🥳

[greg0ire]

Nice job!

[greg0ire]

I think this should target 2.15.x (it's not a bugfix)

[mpdude]

Rebased onto 2.15.x

[SenseException]

👍

[derrabus]

Thank you!