GH-49371: [C++] Work around bit_width not being available on MacOS's partially compatible C++20 build

[jonkeane]

Fixes#49371

Rationale for this change

Stop main from failing

What changes are included in this PR?

Thanks Kou for the suggestion at #49391 (comment)

Are these changes tested?

Yes

Are there any user-facing changes?

No

• GitHub Issue: [C++]: Work around bit_width not being available on MacOS's partially compatible C++20 build #49371

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 632cb49

Submitted crossbow builds: ursacomputing/crossbow @ actions-3e29779128

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5b6a759

Submitted crossbow builds: ursacomputing/crossbow @ actions-971ec12679

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5ea627b

Submitted crossbow builds: ursacomputing/crossbow @ actions-c0a2135a7a

Task	Status
test-r-macos-as-cran

[jonkeane]

The CI failures look like they are #49347 which is also on main.

[Anakin100100]

The failing build #49391 (comment) has compiler version "The CXX compiler identification is AppleClang 17.0.0.17000013" The build that originally succeeded #49298 (comment) was using "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" and this one is using the same one "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" so I'm not certain that the success of this build is due to the changes made. Looks like the workflow is changing here. The build that failed before this one here was also using "-- The CXX compiler identification is AppleClang 17.0.0.17000013".

Looks like Ursa Computing is running two diifferent runners and one them may have an outdated workflow definition.

[kou]

+1

#49405 (comment) was failed with "AppleClang 17.0.0.17000013":

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:56

-- The CXX compiler identification is AppleClang 17.0.0.17000013

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:1774

/Users/runner/work/crossbow/crossbow/arrow/cpp/src/parquet/chunker_internal.cc:89:27: error: no member named 'bit_width' in namespace 'std'
89 | auto target_bits = std::bit_width(static_cast<uint64_t>(target_size));
| ~~~~~^

And the last try succeeded: #49405 (comment)

So this change fixes this problem.

BTW, I think that the important part of this problem is libc++ version not clang version. So I think that the clang version difference isn't important here.

[Anakin100100]

so libc++ is included in MacOSX11.3.1.sdk which is the same across runners and isn't versioned with the compiler?

[kou]

Yes.

[jonkeane]

@kou is exactly right here. Further: looking at when the test-r-macos-as-cran job was run on #49298 it actually was running the old version of this test (note that there's a single job) which means it had code from before we added the new job in #49221.

[jonkeane]

Fixes#49371

Rationale for this change

Stop main from failing

What changes are included in this PR?

Thanks Kou for the suggestion at #49391 (comment)

Are these changes tested?

Yes

Are there any user-facing changes?

No

• GitHub Issue: [C++]: Work around bit_width not being available on MacOS's partially compatible C++20 build #49371

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 632cb49

Submitted crossbow builds: ursacomputing/crossbow @ actions-3e29779128

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5b6a759

Submitted crossbow builds: ursacomputing/crossbow @ actions-971ec12679

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5ea627b

Submitted crossbow builds: ursacomputing/crossbow @ actions-c0a2135a7a

Task	Status
test-r-macos-as-cran

[jonkeane]

The CI failures look like they are #49347 which is also on main.

[Anakin100100]

The failing build #49391 (comment) has compiler version "The CXX compiler identification is AppleClang 17.0.0.17000013" The build that originally succeeded #49298 (comment) was using "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" and this one is using the same one "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" so I'm not certain that the success of this build is due to the changes made. Looks like the workflow is changing here. The build that failed before this one here was also using "-- The CXX compiler identification is AppleClang 17.0.0.17000013".

Looks like Ursa Computing is running two diifferent runners and one them may have an outdated workflow definition.

[kou]

+1

#49405 (comment) was failed with "AppleClang 17.0.0.17000013":

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:56

-- The CXX compiler identification is AppleClang 17.0.0.17000013

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:1774

/Users/runner/work/crossbow/crossbow/arrow/cpp/src/parquet/chunker_internal.cc:89:27: error: no member named 'bit_width' in namespace 'std'
89 | auto target_bits = std::bit_width(static_cast<uint64_t>(target_size));
| ~~~~~^

And the last try succeeded: #49405 (comment)

So this change fixes this problem.

BTW, I think that the important part of this problem is libc++ version not clang version. So I think that the clang version difference isn't important here.

[Anakin100100]

so libc++ is included in MacOSX11.3.1.sdk which is the same across runners and isn't versioned with the compiler?

[kou]

Yes.

[jonkeane]

@kou is exactly right here. Further: looking at when the test-r-macos-as-cran job was run on #49298 it actually was running the old version of this test (note that there's a single job) which means it had code from before we added the new job in #49221.

[jonkeane]

Fixes#49371

Rationale for this change

Stop main from failing

What changes are included in this PR?

Thanks Kou for the suggestion at #49391 (comment)

Are these changes tested?

Yes

Are there any user-facing changes?

No

• GitHub Issue: [C++]: Work around bit_width not being available on MacOS's partially compatible C++20 build #49371

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 632cb49

Submitted crossbow builds: ursacomputing/crossbow @ actions-3e29779128

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5b6a759

Submitted crossbow builds: ursacomputing/crossbow @ actions-971ec12679

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5ea627b

Submitted crossbow builds: ursacomputing/crossbow @ actions-c0a2135a7a

Task	Status
test-r-macos-as-cran

[jonkeane]

The CI failures look like they are #49347 which is also on main.

[Anakin100100]

The failing build #49391 (comment) has compiler version "The CXX compiler identification is AppleClang 17.0.0.17000013" The build that originally succeeded #49298 (comment) was using "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" and this one is using the same one "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" so I'm not certain that the success of this build is due to the changes made. Looks like the workflow is changing here. The build that failed before this one here was also using "-- The CXX compiler identification is AppleClang 17.0.0.17000013".

Looks like Ursa Computing is running two diifferent runners and one them may have an outdated workflow definition.

[kou]

+1

#49405 (comment) was failed with "AppleClang 17.0.0.17000013":

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:56

-- The CXX compiler identification is AppleClang 17.0.0.17000013

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:1774

/Users/runner/work/crossbow/crossbow/arrow/cpp/src/parquet/chunker_internal.cc:89:27: error: no member named 'bit_width' in namespace 'std'
89 | auto target_bits = std::bit_width(static_cast<uint64_t>(target_size));
| ~~~~~^

And the last try succeeded: #49405 (comment)

So this change fixes this problem.

BTW, I think that the important part of this problem is libc++ version not clang version. So I think that the clang version difference isn't important here.

[Anakin100100]

so libc++ is included in MacOSX11.3.1.sdk which is the same across runners and isn't versioned with the compiler?

[kou]

Yes.

[jonkeane]

@kou is exactly right here. Further: looking at when the test-r-macos-as-cran job was run on #49298 it actually was running the old version of this test (note that there's a single job) which means it had code from before we added the new job in #49221.

[jonkeane]

Fixes#49371

Rationale for this change

Stop main from failing

What changes are included in this PR?

Thanks Kou for the suggestion at #49391 (comment)

Are these changes tested?

Yes

Are there any user-facing changes?

No

• GitHub Issue: [C++]: Work around bit_width not being available on MacOS's partially compatible C++20 build #49371

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 632cb49

Submitted crossbow builds: ursacomputing/crossbow @ actions-3e29779128

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5b6a759

Submitted crossbow builds: ursacomputing/crossbow @ actions-971ec12679

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5ea627b

Submitted crossbow builds: ursacomputing/crossbow @ actions-c0a2135a7a

Task	Status
test-r-macos-as-cran

[jonkeane]

The CI failures look like they are #49347 which is also on main.

[Anakin100100]

The failing build #49391 (comment) has compiler version "The CXX compiler identification is AppleClang 17.0.0.17000013" The build that originally succeeded #49298 (comment) was using "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" and this one is using the same one "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" so I'm not certain that the success of this build is due to the changes made. Looks like the workflow is changing here. The build that failed before this one here was also using "-- The CXX compiler identification is AppleClang 17.0.0.17000013".

Looks like Ursa Computing is running two diifferent runners and one them may have an outdated workflow definition.

[kou]

+1

#49405 (comment) was failed with "AppleClang 17.0.0.17000013":

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:56

-- The CXX compiler identification is AppleClang 17.0.0.17000013

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:1774

/Users/runner/work/crossbow/crossbow/arrow/cpp/src/parquet/chunker_internal.cc:89:27: error: no member named 'bit_width' in namespace 'std'
89 | auto target_bits = std::bit_width(static_cast<uint64_t>(target_size));
| ~~~~~^

And the last try succeeded: #49405 (comment)

So this change fixes this problem.

BTW, I think that the important part of this problem is libc++ version not clang version. So I think that the clang version difference isn't important here.

[Anakin100100]

so libc++ is included in MacOSX11.3.1.sdk which is the same across runners and isn't versioned with the compiler?

[kou]

Yes.

[jonkeane]

@kou is exactly right here. Further: looking at when the test-r-macos-as-cran job was run on #49298 it actually was running the old version of this test (note that there's a single job) which means it had code from before we added the new job in #49221.

[jonkeane]

Fixes#49371

Rationale for this change

Stop main from failing

What changes are included in this PR?

Thanks Kou for the suggestion at #49391 (comment)

Are these changes tested?

Yes

Are there any user-facing changes?

No

• GitHub Issue: [C++]: Work around bit_width not being available on MacOS's partially compatible C++20 build #49371

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 632cb49

Submitted crossbow builds: ursacomputing/crossbow @ actions-3e29779128

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5b6a759

Submitted crossbow builds: ursacomputing/crossbow @ actions-971ec12679

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5ea627b

Submitted crossbow builds: ursacomputing/crossbow @ actions-c0a2135a7a

Task	Status
test-r-macos-as-cran

[jonkeane]

The CI failures look like they are #49347 which is also on main.

[Anakin100100]

The failing build #49391 (comment) has compiler version "The CXX compiler identification is AppleClang 17.0.0.17000013" The build that originally succeeded #49298 (comment) was using "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" and this one is using the same one "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" so I'm not certain that the success of this build is due to the changes made. Looks like the workflow is changing here. The build that failed before this one here was also using "-- The CXX compiler identification is AppleClang 17.0.0.17000013".

Looks like Ursa Computing is running two diifferent runners and one them may have an outdated workflow definition.

[kou]

+1

#49405 (comment) was failed with "AppleClang 17.0.0.17000013":

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:56

-- The CXX compiler identification is AppleClang 17.0.0.17000013

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:1774

/Users/runner/work/crossbow/crossbow/arrow/cpp/src/parquet/chunker_internal.cc:89:27: error: no member named 'bit_width' in namespace 'std'
89 | auto target_bits = std::bit_width(static_cast<uint64_t>(target_size));
| ~~~~~^

And the last try succeeded: #49405 (comment)

So this change fixes this problem.

BTW, I think that the important part of this problem is libc++ version not clang version. So I think that the clang version difference isn't important here.

[Anakin100100]

so libc++ is included in MacOSX11.3.1.sdk which is the same across runners and isn't versioned with the compiler?

[kou]

Yes.

[jonkeane]

@kou is exactly right here. Further: looking at when the test-r-macos-as-cran job was run on #49298 it actually was running the old version of this test (note that there's a single job) which means it had code from before we added the new job in #49221.

[jonkeane]

Fixes#49371

Rationale for this change

Stop main from failing

What changes are included in this PR?

Thanks Kou for the suggestion at #49391 (comment)

Are these changes tested?

Yes

Are there any user-facing changes?

No

• GitHub Issue: [C++]: Work around bit_width not being available on MacOS's partially compatible C++20 build #49371

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 632cb49

Submitted crossbow builds: ursacomputing/crossbow @ actions-3e29779128

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5b6a759

Submitted crossbow builds: ursacomputing/crossbow @ actions-971ec12679

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5ea627b

Submitted crossbow builds: ursacomputing/crossbow @ actions-c0a2135a7a

Task	Status
test-r-macos-as-cran

[jonkeane]

The CI failures look like they are #49347 which is also on main.

[Anakin100100]

The failing build #49391 (comment) has compiler version "The CXX compiler identification is AppleClang 17.0.0.17000013" The build that originally succeeded #49298 (comment) was using "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" and this one is using the same one "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" so I'm not certain that the success of this build is due to the changes made. Looks like the workflow is changing here. The build that failed before this one here was also using "-- The CXX compiler identification is AppleClang 17.0.0.17000013".

Looks like Ursa Computing is running two diifferent runners and one them may have an outdated workflow definition.

[kou]

+1

#49405 (comment) was failed with "AppleClang 17.0.0.17000013":

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:56

-- The CXX compiler identification is AppleClang 17.0.0.17000013

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:1774

/Users/runner/work/crossbow/crossbow/arrow/cpp/src/parquet/chunker_internal.cc:89:27: error: no member named 'bit_width' in namespace 'std'
89 | auto target_bits = std::bit_width(static_cast<uint64_t>(target_size));
| ~~~~~^

And the last try succeeded: #49405 (comment)

So this change fixes this problem.

BTW, I think that the important part of this problem is libc++ version not clang version. So I think that the clang version difference isn't important here.

[Anakin100100]

so libc++ is included in MacOSX11.3.1.sdk which is the same across runners and isn't versioned with the compiler?

[kou]

Yes.

[jonkeane]

@kou is exactly right here. Further: looking at when the test-r-macos-as-cran job was run on #49298 it actually was running the old version of this test (note that there's a single job) which means it had code from before we added the new job in #49221.

[jonkeane]

Fixes#49371

Rationale for this change

Stop main from failing

What changes are included in this PR?

Thanks Kou for the suggestion at #49391 (comment)

Are these changes tested?

Yes

Are there any user-facing changes?

No

• GitHub Issue: [C++]: Work around bit_width not being available on MacOS's partially compatible C++20 build #49371

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 632cb49

Submitted crossbow builds: ursacomputing/crossbow @ actions-3e29779128

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5b6a759

Submitted crossbow builds: ursacomputing/crossbow @ actions-971ec12679

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5ea627b

Submitted crossbow builds: ursacomputing/crossbow @ actions-c0a2135a7a

Task	Status
test-r-macos-as-cran

[jonkeane]

The CI failures look like they are #49347 which is also on main.

[Anakin100100]

The failing build #49391 (comment) has compiler version "The CXX compiler identification is AppleClang 17.0.0.17000013" The build that originally succeeded #49298 (comment) was using "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" and this one is using the same one "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" so I'm not certain that the success of this build is due to the changes made. Looks like the workflow is changing here. The build that failed before this one here was also using "-- The CXX compiler identification is AppleClang 17.0.0.17000013".

Looks like Ursa Computing is running two diifferent runners and one them may have an outdated workflow definition.

[kou]

+1

#49405 (comment) was failed with "AppleClang 17.0.0.17000013":

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:56

-- The CXX compiler identification is AppleClang 17.0.0.17000013

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:1774

/Users/runner/work/crossbow/crossbow/arrow/cpp/src/parquet/chunker_internal.cc:89:27: error: no member named 'bit_width' in namespace 'std'
89 | auto target_bits = std::bit_width(static_cast<uint64_t>(target_size));
| ~~~~~^

And the last try succeeded: #49405 (comment)

So this change fixes this problem.

BTW, I think that the important part of this problem is libc++ version not clang version. So I think that the clang version difference isn't important here.

[Anakin100100]

so libc++ is included in MacOSX11.3.1.sdk which is the same across runners and isn't versioned with the compiler?

[kou]

Yes.

[jonkeane]

@kou is exactly right here. Further: looking at when the test-r-macos-as-cran job was run on #49298 it actually was running the old version of this test (note that there's a single job) which means it had code from before we added the new job in #49221.

[jonkeane]

Fixes#49371

Rationale for this change

Stop main from failing

What changes are included in this PR?

Thanks Kou for the suggestion at #49391 (comment)

Are these changes tested?

Yes

Are there any user-facing changes?

No

• GitHub Issue: [C++]: Work around bit_width not being available on MacOS's partially compatible C++20 build #49371

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 632cb49

Submitted crossbow builds: ursacomputing/crossbow @ actions-3e29779128

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5b6a759

Submitted crossbow builds: ursacomputing/crossbow @ actions-971ec12679

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5ea627b

Submitted crossbow builds: ursacomputing/crossbow @ actions-c0a2135a7a

Task	Status
test-r-macos-as-cran

[jonkeane]

The CI failures look like they are #49347 which is also on main.

[Anakin100100]

The failing build #49391 (comment) has compiler version "The CXX compiler identification is AppleClang 17.0.0.17000013" The build that originally succeeded #49298 (comment) was using "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" and this one is using the same one "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" so I'm not certain that the success of this build is due to the changes made. Looks like the workflow is changing here. The build that failed before this one here was also using "-- The CXX compiler identification is AppleClang 17.0.0.17000013".

Looks like Ursa Computing is running two diifferent runners and one them may have an outdated workflow definition.

[kou]

+1

#49405 (comment) was failed with "AppleClang 17.0.0.17000013":

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:56

-- The CXX compiler identification is AppleClang 17.0.0.17000013

https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:1774

/Users/runner/work/crossbow/crossbow/arrow/cpp/src/parquet/chunker_internal.cc:89:27: error: no member named 'bit_width' in namespace 'std'
89 | auto target_bits = std::bit_width(static_cast<uint64_t>(target_size));
| ~~~~~^

And the last try succeeded: #49405 (comment)

So this change fixes this problem.

BTW, I think that the important part of this problem is libc++ version not clang version. So I think that the clang version difference isn't important here.

[Anakin100100]

so libc++ is included in MacOSX11.3.1.sdk which is the same across runners and isn't versioned with the compiler?

[kou]

Yes.

[jonkeane]

@kou is exactly right here. Further: looking at when the test-r-macos-as-cran job was run on #49298 it actually was running the old version of this test (note that there's a single job) which means it had code from before we added the new job in #49221.