ARROW-10306: [C++] Add string replacement kernel

[maartenbreddels]

Two new kernels

• replace_substring like Python's str.replace
• replace_substring_re2 like Python's re.sub

[github-actions]

https://issues.apache.org/jira/browse/ARROW-10306

[pitrou]

You may want to remove the regex variant of this if you want to move this forward without depending on resolving the re2 dependency issue.

[jorisvandenbossche]

@maartenbreddels would it be practical to split this into two PRs? (one for plain replace, other for re2-based replace) Or would you prefer first to have the re2 dependency issue resolved? (ARROW-10541)

[maartenbreddels]

I'd rather keep this 1 PR, looks like #8756 is working

[maartenbreddels]

@pitrou this is ready for review, failure seems unrelated (minio on windows).

[pitrou]

Neat! See comments below.

[pitrou]

ReplaceString below is basically independent from Type, but using this idiom may compile it twice. Can you find another way to parametrize the kernel?
(hint: perhaps use composition rather than inheritance)

[maartenbreddels]

Maybe I misunderstand, but via offset_type we are not independent of Type right?

[pitrou]

Well, I don't understand why offset_type is being used here. ValueDataBuilder is basically a TypedBufferBuilder<uint8_t>, it's used for building the string data, it doesn't deal with string offsets.

[maartenbreddels]

Ok, yes, I see it now. I'm using offset_type in this class as well, which I shouldn't, I think that's what led me to this. This requires a bit of refactoring.

[maartenbreddels]

This pattern occurs more often in the file, I didn't realize this lead to slower compilation and probably larger binary sizes. I think it requires a refactor that is larger than this PR. Also, I won't have the time currently to do this. Can we merge this as is, and I'll open a Jira issue?

[pitrou]

Well, you don't need to refactor other kernels for now, but I suppose this one could easily be adapted, no? :-)

[pitrou]

Similarly as above, this looks basically independent from Type.

[pitrou]

Note that the GlobalReplace loop works a bit differently, it calls Match then Rewrite, avoiding the duplicate matching calls. Not sure it's worth optimizing this, though:
https://github.com/google/re2/blob/master/re2/re2.cc#L427

[maartenbreddels]

Good idea, I prefer to keep it as it is, I left a comment in the code so this doesn't get lost.

[pitrou]

@maartenbreddels Is it ready for review again? Feel free to ping me.

[maartenbreddels]

@pitrou Yes, apart from an unanswered question this is ready for review 👍

[maartenbreddels]

@pitrou this is ready for review (assuming you agree with the above plan of doing a refactor later on)

[jorisvandenbossche]

(gentle ping here, would really like to see those PRs merged for 4.0 in April!)

[pitrou]

I'll rebase and update this PR.

[pitrou]

Hmm, there's a re2 link error on RTools 3.5:
https://github.com/pitrou/arrow/runs/2195976671?check_suite_focus=true#step:12:178

@nealrichardson

[nealrichardson]

Haven't seen that before, and we've been building with re2 for months now. Maybe this is the first time we're building something that actually uses re2? It's possible that re2 needs a "backport" library built with the rtools3.5 toolchain; an immediate workaround could be to build with -DRE2_SOURCE=BUNDLED here, or to make ARROW_WITH_RE2 conditional on the toolchain (like we do for ARROW_S3 already). Given that we won't have to support the rtools3.5 toolchain after April or May, I'll try just turning it off here.

[nealrichardson]

@github-actions crossbow submit -g r

[github-actions]

Revision: 82bb60d

Submitted crossbow builds: ursacomputing/crossbow @ actions-233

Task	Status
conda-linux-gcc-py36-cpu-r36
conda-linux-gcc-py37-cpu-r40
conda-osx-clang-py36-r36
conda-osx-clang-py37-r40
conda-win-vs2017-py36-r36
conda-win-vs2017-py37-r40
homebrew-r-autobrew
test-r-install-local
test-r-linux-as-cran
test-r-minimal-build
test-r-rhub-ubuntu-gcc-release
test-r-rocker-r-base-latest
test-r-rstudio-r-base-3.6-bionic
test-r-rstudio-r-base-3.6-centos7-devtoolset-8
test-r-rstudio-r-base-3.6-centos8
test-r-rstudio-r-base-3.6-opensuse15
test-r-rstudio-r-base-3.6-opensuse42
test-r-version-compatibility
test-r-versions
test-ubuntu-18.04-r-sanitizer

[nealrichardson]

The as-cran failure is legit: https://github.com/ursacomputing/crossbow/runs/2197449739?check_suite_focus=true#step:7:210

It's a weird build setup that uses clang and -stdlib=libc++; unfortunately we have to support it because it's one of CRAN's checks. But I'll deal with this in a followup.

[nealrichardson]

I made ARROW-12094 for fixing that build. Merging now.