This repository was archived by the owner on Aug 21, 2018. It is now read-only.
Parsing US number succeeds in tests fails in actual usage #4
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.
US number parsing fails because different data is used for countryCallingCodeToRegionCodeMap while testing and actual usage. The mapping for global networks (880 => 001) is present in countryCallingCodeToRegionCodeMapForTesting but not in countryCallingCodeToRegionCodeMap.
When the init() is called inside PhoneNumberUtil::getInstance(), it removes US from the supportedRegions array.
At line, http://git.io/CLseew#L235
unset($this->supportedRegions[array_search(self::REGION_CODE_FOR_NON_GEO_ENTITY, $this->supportedRegions)]) resolves to
unset($this->supportedRegions[array_search(001, $this->supportedRegions)])
Because the mapping doesn't exist for 001, array_search returns FALSE executing unset($this->supportedRegions[FALSE].
As unset(array[FALSE]) is equivalent to unset(array[0]), it unset the entry for US from the supportedRegions as index for US is 0 in the array.
Hence, parsing US number results into error.
I have attached a possible solution. Please validate and pull.