-
Notifications
You must be signed in to change notification settings - Fork 3.7k
GH-39138: [R] Fix implicit conversion warnings #39250
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
Conversation
|
@github-actions crossbow submit test-r-install-local |
Revision: 814e712 Submitted crossbow builds: ursacomputing/crossbow @ actions-ba1f272e1d
|
@github-actions crossbow submit test-r-install-local |
Revision: 97d3713 Submitted crossbow builds: ursacomputing/crossbow @ actions-523036ada2
|
@github-actions crossbow submit --group r |
Revision: d3b8acc Submitted crossbow builds: ursacomputing/crossbow @ actions-bfb08e2c71 |
@ursabot please benchmark |
Benchmark runs are scheduled for commit d3b8acc. Watch https://buildkite.com/apache-arrow and https://conbench.ursa.dev for updates. A comment will be posted here when the runs are complete. |
The benchmark that is through seems to show some regressions? But I also don't have practice in interpreting these: https://conbench.ursa.dev/compare/runs/e13bb0a5533349c094f88b39316be8e3...0d58238a60974b3facaf13de17fad7f7/ |
Thanks for your patience. Conbench analyzed the 6 benchmarking runs that have been run so far on PR commit d3b8acc. There was 1 benchmark result indicating a performance regression:
The full Conbench report has more details. |
I don't see any R-related regressions? (Even if there were, it would have been because a check was added that increases safety, although I don't think I added any additional out-of-bounds checks in places with tight loops). |
Overall LGTM! (Caveat: I haven't reviewed much C++ code recently) |
There is a lot of downcasting taking place in Arrow R. Any idea if this was an intentional decision due to some 32bit limitation? |
By default, I think you would be hard pressed to find loss of precision happening. The main place that this could happen without explicit user intervention is (1) when converting timestamps to R with subsecond precision (limitation of R, we store timestamps as seconds with double precision) and (2) factors with more then INT_MAX elements in a dictionary (limitation of R, factors are int under the hood). Other downcasting that happens requires intervention from the user (i.e., I think we can do better in all cases, but we still wouldn't do that checking or erroring at the element level (i.e., where the |
Sorry I forgot which PR this is 🤦♂️ |
r/src/altrep.cpp
Outdated
@@ -613,11 +615,14 @@ struct AltrepFactor : public AltrepVectorBase<AltrepFactor> { | |||
case Type::INT32: | |||
return indices->data()->GetValues<int32_t>(1)[j] + 1; | |||
case Type::UINT32: | |||
return indices->data()->GetValues<uint32_t>(1)[j] + 1; | |||
// TODO: check index? |
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.
You should consider changing the return type of this function to int64_t
instead.
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.
And you can postpone all the refactoring by renaming this function and adding a wrapper with this signature with the sole purpose of converting the int64_t
returned by this modified function to int
. Then you have to write the casts and check in a single place.
r/src/altrep.cpp
Outdated
@@ -718,7 +723,8 @@ struct AltrepFactor : public AltrepVectorBase<AltrepFactor> { | |||
|
|||
VisitArraySpanInline<Type>( | |||
*array->data(), | |||
/*valid_func=*/[&](index_type index) { *out++ = transpose(index) + 1; }, | |||
/*valid_func=*/ | |||
[&](index_type index) { *out++ = static_cast<int>(transpose(index) + 1); }, |
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.
Could out
be changed to be an int64_t
?
@@ -802,7 +808,8 @@ struct AltrepVectorString : public AltrepVectorBase<AltrepVectorString<Type>> { | |||
} | |||
|
|||
nul_was_stripped_ = true; | |||
return Rf_mkCharLenCE(stripped_string_.data(), stripped_len, CE_UTF8); | |||
return Rf_mkCharLenCE(stripped_string_.data(), static_cast<int>(stripped_len), |
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.
Here, a DCHECK_LE(stripped_len, std::numeric_limits<int>::max())
would be useful since there is no way to change what Rf_mkCharLenCE
receives.
Thank you @felipecrv and @danepitkin for the feedback (and sorry to everybody for taking a few days to circle back here...I wanted to make sure I addressed the comments properly!). I added a |
### Rationale for this change We have failing CRAN checks because this warning occurs on one check machine. ### What changes are included in this PR? Implicit integer casts are made explicit and/or variable declarations were fixed so that fewer implicit integer casts were performed. Fully solving the warnings also requires r-lib/cpp11#349 since some errors occur in those headers. ### Are these changes tested? This particular test we can't do on CI because the MacOS runner we have doesn't have a new enough `clang` to support the requisite `-W` flags. I tested this locally by adding `PKG_CXXFLAGS=-Wconversion -Wno-sign-conversion -Wsign-compare -Werror` to `Makevars.in`. ### Are there any user-facing changes? No * Closes: #39138 Authored-by: Dewey Dunnington <[email protected]> Signed-off-by: Dewey Dunnington <[email protected]>
After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit 7b71156. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 10 possible false positives for unstable benchmarks that are known to sometimes produce them. |
### Rationale for this change We have failing CRAN checks because this warning occurs on one check machine. ### What changes are included in this PR? Implicit integer casts are made explicit and/or variable declarations were fixed so that fewer implicit integer casts were performed. Fully solving the warnings also requires r-lib/cpp11#349 since some errors occur in those headers. ### Are these changes tested? This particular test we can't do on CI because the MacOS runner we have doesn't have a new enough `clang` to support the requisite `-W` flags. I tested this locally by adding `PKG_CXXFLAGS=-Wconversion -Wno-sign-conversion -Wsign-compare -Werror` to `Makevars.in`. ### Are there any user-facing changes? No * Closes: apache#39138 Authored-by: Dewey Dunnington <[email protected]> Signed-off-by: Dewey Dunnington <[email protected]>
### Rationale for this change We have failing CRAN checks because this warning occurs on one check machine. ### What changes are included in this PR? Implicit integer casts are made explicit and/or variable declarations were fixed so that fewer implicit integer casts were performed. Fully solving the warnings also requires r-lib/cpp11#349 since some errors occur in those headers. ### Are these changes tested? This particular test we can't do on CI because the MacOS runner we have doesn't have a new enough `clang` to support the requisite `-W` flags. I tested this locally by adding `PKG_CXXFLAGS=-Wconversion -Wno-sign-conversion -Wsign-compare -Werror` to `Makevars.in`. ### Are there any user-facing changes? No * Closes: apache#39138 Authored-by: Dewey Dunnington <[email protected]> Signed-off-by: Dewey Dunnington <[email protected]>
Rationale for this change
We have failing CRAN checks because this warning occurs on one check machine.
What changes are included in this PR?
Implicit integer casts are made explicit and/or variable declarations were fixed so that fewer implicit integer casts were performed. Fully solving the warnings also requires r-lib/cpp11#349 since some errors occur in those headers.
Are these changes tested?
This particular test we can't do on CI because the MacOS runner we have doesn't have a new enough
clang
to support the requisite-W
flags. I tested this locally by addingPKG_CXXFLAGS=-Wconversion -Wno-sign-conversion -Wsign-compare -Werror
toMakevars.in
.Are there any user-facing changes?
No
-Wconversion
on clang15 results in compiler warnings #39138