Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix psalm errors: remove override of template type #11385

Closed
wants to merge 759 commits into from

Conversation

tantegerda1
Copy link
Contributor

See doctrine/collections#368 for the same issue in doctrine/collections which has been fixed there.

The issue happens when using ->contains(). Running psalm emits

InvalidArgument - Argument 1 of Doctrine\ORM\PersistentCollection::contains expects TMaybeContained:fn-doctrine\common\collections\readablecollection::contains as mixed, but … provided.

We should either not define @template TMaybeContained or re-define the psalm docblock from ReadableCollection completely.

greg0ire and others added 30 commits May 5, 2023 21:02
Instead of ensuring every mapping array has a mappedBy and an inversedBy
field, let us do the opposite, and remove them when they are null.
Likewise if there is a joinColumns field, it is useless if null or
empty.
- Each type is now either final, abstract or an interface.
- The mappedBy attribute is no longer nullable and moved down the
  hierarchy.
- The inversedBy attribute is still nullable and also moved down the
  hierarchy.
- Code common to ManyToOneAssociationMapping and
  OneToOneOwningSideMapping is de-duplicated and moved up the hierarchy
- Code inside ToManyInverseSideMapping and ToManyOwningSideMapping comes
  from a trait to avoid duplication.
Interfaces cannot have properties, and we do not have a concept of
sealed classes available to us without installing third party packages.
Interfaces can have methods however, which allows us to simplify calling
code.
I've been avoiding introducing getters for mapping properties because I
do not know what the performance implications are, but here, I think it
is sensible to make an exception, given the benefits.
Throughout the codebase, there is this pattern where we ensure we have
the owning side of an association.
It involves accessing it from the associationMappings array. In the end,
static analysis cannot know that the association is indeed owning.
By introducing this convenience method, we make this clear, and also
delegate the complexity to the class metadata factory.
Introduce method to get to the owning side
It allows to remove many assertions.
It has only meaning for ToOneOwningSideMapping
…dnames-down

Move joinColumnFieldNames down the class hierarchy
The keys in the join columns array have no meaning, and are just
sequential integers.
These methods assert the type of the mapping provided by the collection
according to the name of the class they are in: the one to many
persister only ever deals with one to many associations, and the many to
many persister only ever deals with many to many associations.
…ping-type

Narrow down ClassMetadata::associationMappings type
Introduce convenience methods to narrow types
Maybe we do not know enough about the parameter to determine the type of
the returned relationship, but we can at least narrow it down to 3
possibilites.
Not sure how I forgot these.
…e-qs

Narrow down parameter types for quote strategies
derrabus and others added 19 commits March 1, 2024 08:56
* 3.0.x:
  Use enum_exists() for enums
* Use class from persistence package

It is meant to remove duplication between the ORM and the ODM.

* Update UPGRADE.md

Co-authored-by: Steve Todd <[email protected]>

---------

Co-authored-by: Alexander M. Turek <[email protected]>
Co-authored-by: Steve Todd <[email protected]>
* 2.19.x:
  Refator array_map into simple loop for performance. (doctrine#11332)
* 2.18.x:
  Fix annotation
  Bump CI workflows (doctrine#11336)
  Fix SchemaTool::getSchemaFromMetadata() uniqueConstraint without a predefined name (doctrine#11314)
* 3.0.x:
  Fix annotation
  Bump CI workflows (doctrine#11336)
  Fix SchemaTool::getSchemaFromMetadata() uniqueConstraint without a predefined name (doctrine#11314)
* 2.19.x:
  Prepare releases 2.19 and 3.1 (doctrine#11335)
It is deprecated.
@derrabus
Copy link
Member

Psalm and PHPCS are failing.

@tantegerda1
Copy link
Contributor Author

Updated to address these issues (good that there is a strict CI watching my rookie commits…).

The remaining failing check seems unrelated.

@greg0ire
Copy link
Member

Restarted the job, it now passes.

@greg0ire
Copy link
Member

Please kindly squash your commits together. If you don't, we'll try to remember to do it for you but it's best if you save us this trouble.

How to do that?

  1. git rebase -i origin/3.1.x, assuming origin is a git remote that points to this repository, and not your fork. If you're not sure what your remotes are, run git remote -vvv, there should be your fork and the holy/reference/base/origin/whatever-you-call-it repository.
  2. A window will show up with many lines, replace pick with fixup on every line but the first one
  3. Close your editor, git should do its magic, and you should end up with one commit
  4. Use git push --force to overwrite what you already push. Don't forget the --force option otherwise git will try to merge both things together.

See doctrine/collections#368 for the same
issue in doctrine/collections which has been fixed there.

The issue happened when using ->contains(). Running psalm emitted

  > InvalidArgument - Argument 1 of Doctrine\ORM\PersistentCollection::contains
  > expects
  > TMaybeContained:fn-doctrine\common\collections\readablecollection::contains
  > as mixed, but … provided.

We should either not define @template TMaybeContained or re-define
the psalm docblock from ReadableCollection completely.

Repairing the docblock necessitates an update to the psalm baseline:
one "known issue" is no longer an issue and could thus be removed.
@tantegerda1 tantegerda1 changed the base branch from 3.1.x to 2.19.x March 20, 2024 21:44
@tantegerda1
Copy link
Contributor Author

Sorry. I started from the wrong branch. Failed to see #11208 How to choose the right branch.

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

Successfully merging this pull request may close these issues.