GH-46439: [C++] Use result pattern for all FromJSONString Helpers

[amoeba]

Rationale for this change

#45908 brought these helpers into the public API but didn't consider changes to their API. This PR makes all the helpers use the standard Result-pattern to make them more ergonomic. We can do this now without a breaking change because this and #45908 will be part of Arrow 21.

What changes are included in this PR?

• Refactored all FromJSONString helpers to use the Result pattern (instead of using outparams)

Are these changes tested?

Yes.

Are there any user-facing changes?

No.

• GitHub Issue: [C++] Address post-merge review comments in PR exposing {Array,...}FromJSON helpers in public API #46439

[amoeba]

Thanks @kou for the quick review. I fixed what I could and left one conversation open in #46696 (comment).

I'll hold off on rebasing to fix the merge conflict until after review is over.

[amoeba]

Rebased, all outstanding review comments addressed.

[kou]

+1

[amoeba]

Looks like there are some issues with gdb.cc I need to figure out. I get this,

[ 24%] Building CXX object CMakeFiles/arrow_python.dir/pyarrow/src/arrow/python/gdb.cc.o
/Users/bryce/src/apache/arrow/python/pyarrow/src/arrow/python/gdb.cc:367:12: error: expected '(' for function-style cast or type construction
  367 |       auto heap_map_scalar,
      |       ~~~~ ^
/Users/bryce/src/apache/arrow/python/pyarrow/src/arrow/python/gdb.cc:369:46: error: use of undeclared identifier 'heap_map_scalar'
  369 |   auto heap_map_scalar_null = MakeNullScalar(heap_map_scalar->type);
      |                                              ^
/Users/bryce/src/apache/arrow/python/pyarrow/src/arrow/python/gdb.cc:482:29: error: expected '(' for function-style cast or type construction
  482 |   ASSERT_OK_AND_ASSIGN(auto col1,
      |                        ~~~~ ^
/Users/bryce/src/apache/arrow/python/pyarrow/src/arrow/python/gdb.cc:485:12: error: expected '(' for function-style cast or type construction
  485 |       auto col2, ChunkedArrayFromJSONString(
      |       ~~~~ ^
/Users/bryce/src/apache/arrow/python/pyarrow/src/arrow/python/gdb.cc:487:43: error: use of undeclared identifier 'col1'
  487 |   auto table = Table::Make(batch_schema, {col1, col2});
      |                                           ^
/Users/bryce/src/apache/arrow/python/pyarrow/src/arrow/python/gdb.cc:487:49: error: use of undeclared identifier 'col2'
  487 |   auto table = Table::Make(batch_schema, {col1, col2});
      |                                                 ^
6 errors generated.

[amoeba]

I think the gdb.cc errors are fixed in 641839f. I realize we can't use those helpers and that it's fine to just ValueOrDie (directly or via operator*). Watching CI now.

[amoeba]

CI looks good now, I had two fix a couple of issues with gdb.cc. @kou do you want to take one more look at that file before we merge?

[kou]

+1

[amoeba]

Thank you as always @kou

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit c85c3d0.

There were 71 benchmark results with an error:

• Commit Run on arm64-t4g-2xlarge-linux at 2025-06-05 03:10:59Z
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-07, scale_factor=1
  • tpch (R) with engine=arrow, format=native, language=R, memory_map=False, query_id=TPCH-09, scale_factor=1
• and 69 more (see the report linked below)

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 53 possible false positives for unstable benchmarks that are known to sometimes produce them.