-
Notifications
You must be signed in to change notification settings - Fork 653
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
Do not report serialize as unused #8650
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it would work for anything but the simplest cases. E.g.
serialize([new RuntimeException]);
would still be marked as unused, wouldn't it?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to avoid the error for
String[] but didnt think about object[] indeed.
Do you see an easy way to improve this or should we test for lot of atomic types ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@orklah @weirdan Seems like this work #8652
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general,
serialize()
is impure when it operates on anything that may contain an object. Your PRs are focusing on the cases whenserialize()
is called on something that does contain an object. The distinction is important because there are supertypes to object types, such asobject|int
oriterable
ormixed
. In all of those casesserialize()
should be considered impure:However, that's only a part of the problem. The other part is that the types that may contain objects could themselves be a part of an arbitrarily deep type. Say you fixed the case of
serialize([new stdClass]);
, but then you have to fixserialize([[new stdClass]]);
(note the array depth) and so on.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ContainsObjectTypeVisitor is supposed to resolve the array depth issue, I can add a test about it
For the "may contain an object" issue, I'm not sure how I should change my
check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried and didn't succeed to use this function because it doesn't work for arrays.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The type visitor approach is fine, you can just use
TypeComparator
(eitherUnion*
orAtomic*
, depending on what the visitor gets) to compare individual type parts.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This way, you'd be able to handle
iterable[][]
, for example.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the PR, it works with the previous test but still doesn't work with mixed or iterable.
Did I mess up with the check:
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think the types should be the other way around. The container is the
$type
in this case, and the$input_type
isobject
, because you want to check whether theobject
can be contained by the$type
.You may have to allow coercion (not sure if that method allows it, but there should be one that does) because
object
is not strictly contained by, e.g.,ClassName|int
, but it can be coerced into.