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

Bug: DOMText::nodeValue can be null #7479

Closed
ThomasLandauer opened this issue Jan 24, 2022 · 7 comments
Closed

Bug: DOMText::nodeValue can be null #7479

ThomasLandauer opened this issue Jan 24, 2022 · 7 comments
Labels
bug easy problems Issues that can be fixed without background knowledge of Psalm Help wanted internal stubs/callmap

Comments

@ThomasLandauer
Copy link
Contributor

This is related to #1965

is_string($domText->nodeValue) results in:

RedundantCondition - 4:5 - Type string for $domText->nodeValue is always string

https://psalm.dev/r/a1bfbfe662

But https://www.php.net/manual/class.domtext.php says:

public ?string $nodeValue;
@psalm-github-bot
Copy link

I found these snippets:

https://psalm.dev/r/a1bfbfe662
<?php

$a = new \DOMText();
if (is_string($a->nodeValue)) {
    //
}
Psalm output (using commit c7d938b):

ERROR: RedundantCondition - 4:5 - Type string for $a->nodeValue is always string

@orklah
Copy link
Collaborator

orklah commented Jan 24, 2022

Thanks for reporting! Care for a PR?

@orklah orklah added bug easy problems Issues that can be fixed without background knowledge of Psalm Help wanted internal stubs/callmap labels Jan 24, 2022
@KevinVanSonsbeek
Copy link
Contributor

KevinVanSonsbeek commented Jan 27, 2022

It seems it might be caused by this line.

'nodeValue' => 'string',

On the DOMNode the property is nullable (so the PropertyMap should be changed), but the docs do mention this:

Contrary to the W3C specification, the node value of DOMElement nodes is equal to DOMNode::textContent instead of null.
So in the context of a DOMElement it seems it should not be able to return null

Which could be interpreted as meaning that on DOMElement's, the nodeValue property will always return a string. As the textContent is not nullable.

Edit: I can't really find any code in the source code indicating different behavior of the property on the DOMElement though. But i am not sure how to figure out if that statement on the docs is correct or not.

@AndrolGenhald
Copy link
Collaborator

AndrolGenhald commented Jan 27, 2022

Edit: I can't really find any code in the source code indicating different behavior of the property on the DOMElement though. But i am not sure how to figure out if that statement on the docs is correct or not.

I'm guessing it's this.

On the other hand, this says that can be nullable as well, so there would have to be some other guarantee that content is always available. I'm guessing it's never null for an xmlElement, but I'm not 100% sure.

Looks like it could be null due to memory allocation failure. That might be ok to ignore, if it fails to allocate that there's a really high chance PHP is going to crash extremely soon anyway.

@KevinVanSonsbeek
Copy link
Contributor

Mhm, looking at this code it seems they opted to return an empty string, rather than return null if they can't get the content?

@AndrolGenhald
Copy link
Collaborator

AndrolGenhald commented Jan 27, 2022

That's for textContent though, not nodeValue.

Given that that check exists for textContent but not nodeValue I'd err towards caution and leave nodeValue as nullable for DOMElement.

orklah added a commit that referenced this issue Jan 27, 2022
…odevalue-can-be-null

BugFix: Made DOMNode::nodeValue nullable
@KevinVanSonsbeek
Copy link
Contributor

Should be fixed by #7501

@orklah orklah closed this as completed Jan 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug easy problems Issues that can be fixed without background knowledge of Psalm Help wanted internal stubs/callmap
Projects
None yet
Development

No branches or pull requests

4 participants