Fix vec_ptype2() fallback path when LHS is NULL
#2128
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.
Closes #2127
Closes #1981
The goal of this PR was to fix this small
x_type->y_typetypo herevctrs/src/ptype2.c
Line 71 in 29c5518
But since that is run as the very first iteration of almost every
vec_ptype_common()call (because we start the reduction withx = NULL, y = xs[[1]]), it had a huge amount of fallout of weird buggy cases that relied on this.I think pretty much every change I had to make was a net improvement. The sf commit was particularly complicated though.
One other meaningful change is that I've added
vec_ptype.POSIXlt(), which returns a correspondingPOSIXct, so thatvec_ptype_common(<POSIXlt>)andvec_ptype_common(<POSIXlt>, <POSIXlt>)consistently return aPOSIXct, which has implications forvec_c(x)andvec_c(x, x)as well (now both returnPOSIXct).Best to look at these commits one at a time.