pytorch - 💡(How to fix) Fix Compilation fails with Apple Clang 17 due to ambiguous py::make_tuple return types [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
pytorch/pytorch#178044Fetched 2026-04-08 01:07:28
View on GitHub
Comments
1
Participants
2
Timeline
25
Reactions
0
Author
Participants
Timeline (top)
referenced ×13mentioned ×4subscribed ×4labeled ×2

Error Message

torch/csrc/jit/python/init.cpp:1833:11: error: return type 'Tuple<pybind11::cpp_function &, pybind11::list &>' must match previous return type 'Tuple<pybind11::none, pybind11::none>' when lambda expression has unspecified explicit return type

torch/csrc/jit/python/init.cpp:1860:11: error: return type 'Tuple<[...], pybind11::none>' must match previous return type 'Tuple<[...], pybind11::object &>' when lambda expression has unspecified explicit return type

torch/csrc/utils/python_arg_parser.cpp:763:7: error: conditional expression is ambiguous; 'Tuple<[2 * ...], (no argument)>' can be converted to 'Tuple<[2 * ...], pybind11::handle>' and vice versa

Code Example

torch/csrc/jit/python/init.cpp:1833:11: error: return type 'Tuple<pybind11::cpp_function &, pybind11::list &>' must match previous return type 'Tuple<pybind11::none, pybind11::none>' when lambda expression has unspecified explicit return type

torch/csrc/jit/python/init.cpp:1860:11: error: return type 'Tuple<[...], pybind11::none>' must match previous return type 'Tuple<[...], pybind11::object &>' when lambda expression has unspecified explicit return type

torch/csrc/utils/python_arg_parser.cpp:763:7: error: conditional expression is ambiguous; 'Tuple<[2 * ...], (no argument)>' can be converted to 'Tuple<[2 * ...], pybind11::handle>' and vice versa

---

py::object args = (val == nullptr)
    ? py::make_tuple(py::handle(self), py::handle(index))
    : py::make_tuple(py::handle(self), py::handle(index), py::handle(val));

---

// _jit_get_operation
// Before:
return py::make_tuple(py::none(), py::none());
// ...
return py::make_tuple(func, overload_names);

// After:
return py::make_tuple(py::cast<py::object>(py::none()), py::cast<py::object>(py::none()));
// ...
return py::make_tuple(py::cast<py::object>(func), py::cast<py::object>(overload_names));

// _maybe_call_torch_function_for_op_packet
// Before:
return py::make_tuple(true, *res);
// ...
return py::make_tuple(false, py::none());

// After:
return py::make_tuple(py::cast<py::object>(py::bool_(true)), py::cast<py::object>(*res));
// ...
return py::make_tuple(py::cast<py::object>(py::bool_(false)), py::cast<py::object>(py::none()));

---

// Before:
py::object args = (val == nullptr)
    ? py::make_tuple(py::handle(self), py::handle(index))
    : py::make_tuple(py::handle(self), py::handle(index), py::handle(val));

// After:
py::object args;
if (val == nullptr) {
  args = py::make_tuple(py::handle(self), py::handle(index));
} else {
  args = py::make_tuple(py::handle(self), py::handle(index), py::handle(val));
}
RAW_BUFFERClick to expand / collapse

🐛 Describe the bug

Several files fail to compile with Apple Clang 17.0.0 (Xcode 26.3) due to ambiguous py::make_tuple return types in lambdas and ternary expressions. The compiler cannot deduce a common return type when branches produce py::make_tuple with different pybind11 element types.

Errors

torch/csrc/jit/python/init.cpp:1833:11: error: return type 'Tuple<pybind11::cpp_function &, pybind11::list &>' must match previous return type 'Tuple<pybind11::none, pybind11::none>' when lambda expression has unspecified explicit return type

torch/csrc/jit/python/init.cpp:1860:11: error: return type 'Tuple<[...], pybind11::none>' must match previous return type 'Tuple<[...], pybind11::object &>' when lambda expression has unspecified explicit return type

torch/csrc/utils/python_arg_parser.cpp:763:7: error: conditional expression is ambiguous; 'Tuple<[2 * ...], (no argument)>' can be converted to 'Tuple<[2 * ...], pybind11::handle>' and vice versa

Affected code

1. torch/csrc/jit/python/init.cpp, _jit_get_operation (lines 1800–1840): one branch returns py::make_tuple(py::none(), py::none()), the other returns py::make_tuple(func, overload_names) where func is a py::cpp_function and overload_names is a py::list.

2. torch/csrc/jit/python/init.cpp, _maybe_call_torch_function_for_op_packet (lines 1844–1862): one branch returns py::make_tuple(true, *res) (bool + py::object), the other returns py::make_tuple(false, py::none()) (bool + py::none).

3. torch/csrc/utils/python_arg_parser.cpp (line 762): ternary with py::make_tuple of different arities (2 vs 3 elements):

py::object args = (val == nullptr)
    ? py::make_tuple(py::handle(self), py::handle(index))
    : py::make_tuple(py::handle(self), py::handle(index), py::handle(val));

Suggested fix

For cases 1 and 2, explicitly cast tuple elements to py::object so all branches produce the same return type:

// _jit_get_operation
// Before:
return py::make_tuple(py::none(), py::none());
// ...
return py::make_tuple(func, overload_names);

// After:
return py::make_tuple(py::cast<py::object>(py::none()), py::cast<py::object>(py::none()));
// ...
return py::make_tuple(py::cast<py::object>(func), py::cast<py::object>(overload_names));

// _maybe_call_torch_function_for_op_packet
// Before:
return py::make_tuple(true, *res);
// ...
return py::make_tuple(false, py::none());

// After:
return py::make_tuple(py::cast<py::object>(py::bool_(true)), py::cast<py::object>(*res));
// ...
return py::make_tuple(py::cast<py::object>(py::bool_(false)), py::cast<py::object>(py::none()));

For case 3, replace the ternary with an if/else:

// Before:
py::object args = (val == nullptr)
    ? py::make_tuple(py::handle(self), py::handle(index))
    : py::make_tuple(py::handle(self), py::handle(index), py::handle(val));

// After:
py::object args;
if (val == nullptr) {
  args = py::make_tuple(py::handle(self), py::handle(index));
} else {
  args = py::make_tuple(py::handle(self), py::handle(index), py::handle(val));
}

Versions

Collecting environment information... PyTorch version: 2.10.0a0 Is debug build: False CUDA used to build PyTorch: None ROCM used to build PyTorch: N/A

OS: macOS 26.3.1 (arm64) GCC version: Could not collect Clang version: 17.0.0 (clang-1700.6.4.2) CMake version: version 3.31.10 Libc version: N/A

Python version: 3.14.3 (main, Feb 7 2026, 05:34:13) [Clang 17.0.0 (clang-1700.6.3.2)] (64-bit runtime) Python platform: macOS-26.3.1-arm64-arm-64bit-Mach-O Is CUDA available: False CUDA runtime version: No CUDA CUDA_MODULE_LOADING set to: N/A GPU models and configuration: No CUDA Nvidia driver version: No CUDA cuDNN version: No CUDA Is XPU available: False HIP runtime version: N/A MIOpen runtime version: N/A Is XNNPACK available: True Caching allocator config: N/A

CPU: Apple M4

Versions of relevant libraries: [pip3] mypy==1.19.1 [pip3] mypy_extensions==1.1.0 [pip3] numpy==2.4.3 [pip3] oldest-supported-numpy==0.1 [pip3] onnx==1.20.0 [pip3] torch==2.10.0a0+gitunknown [pip3] torchaudio==2.10.0 [pip3] torchdiffeq==0.2.5 [conda] Could not collect

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel

extent analysis

Fix Plan

To resolve the compilation issues with Apple Clang 17.0.0, follow these steps:

  • Explicitly cast tuple elements to py::object in _jit_get_operation and _maybe_call_torch_function_for_op_packet to ensure all branches produce the same return type.
  • Replace the ternary expression in torch/csrc/utils/python_arg_parser.cpp with an if/else statement to avoid ambiguity.

Code Changes

1. _jit_get_operation

// Before:
return py::make_tuple(py::none(), py::none());
// ...
return py::make_tuple(func, overload_names);

// After:
return py::make_tuple(py::cast<py::object>(py::none()), py::cast<py::object>(py::none()));
// ...
return py::make_tuple(py::cast<py::object>(func), py::cast<py::object>(overload_names));

2. _maybe_call_torch_function_for_op_packet

// Before:
return py::make_tuple(true, *res);
// ...
return py::make_tuple(false, py::none());

// After:
return py::make_tuple(py::cast<py::object>(py::bool_(true)), py::cast<py::object>(*res));
// ...
return py::make_tuple(py::cast<py::object>(py::bool_(false)), py::cast<py::object>(py::none()));

3. torch/csrc/utils/python_arg_parser.cpp

// Before:
py::object args = (val == nullptr)
    ? py::make_tuple(py::handle(self), py::handle(index))
    : py::make_tuple(py::handle(self), py::handle(index), py::handle(val));

// After:
py::object args;
if (val == nullptr) {
  args = py::make_tuple(py::handle(self), py::handle(index));
} else {
  args = py::make_tuple(py::handle(self), py::handle(index), py::handle(val));
}

Verification

After applying these changes, recompile the code using Apple Clang 17.0.0 to verify that the issues are resolved.

Extra Tips

  • Ensure that all tuple elements are explicitly cast to py::object to avoid ambiguity.
  • Replace ternary expressions with if/else statements when dealing with py::make_tuple to maintain clarity and avoid potential compilation issues.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

pytorch - 💡(How to fix) Fix Compilation fails with Apple Clang 17 due to ambiguous py::make_tuple return types [1 comments, 2 participants]