Fix dynamo export for scalar mul on converted real tensors

[Copilot]

torch.onnx.export(..., dynamo=True) could fail when a real-valued tensor produced by convert_element_type was multiplied by a scalar literal (aten.mul.Scalar / aten.multiply.Scalar). In the 2.13+ export path, that overload was missing from the torch-lib registrations, so FX translation raised a dispatch error even though the lowering is a standard scalar multiply.

• Summary

  • Add the missing scalar-multiply overloads to the torch-lib op set.
  • Keep scalar multiply behavior consistent with existing scalar arithmetic overloads.
  • Cover the reported convert_element_type + * 1.0 pattern with a regression case.

• Change

  • In onnxscript/function_libs/torch_lib/ops/core.py, registered:
    • aten::mul.Scalar
    • aten::multiply.Scalar
  • These lower to the same tensor multiplication logic already used for aten::mul and preserve the expected scalar-to-tensor promotion behavior.
  • This prevents the Dynamo export path from failing on real-valued tensors after type conversion.

• Example

class Model(torch.nn.Module):
    def forward(self, x):
        return x.to(torch.float32) * 1.0

This is the same shape as the failing export pattern: a scalar multiply applied to a convert_element_type result, which previously hit a missing ONNX function registration during translation.

• Fixes torch.onnx.export (dynamo): ConversionError — No ONNX function for aten.mul.Scalar with real-valued input (regression in 2.13.0) pytorch/pytorch#194382

[Justin Chu (justinchuby)]

Copilot also fix pytorch/pytorch#194381 and errors of this class

[Copilot]

Copilot also fix pytorch/pytorch#194381 and errors of this class

This class of issue is covered by the missing scalar-multiply registrations in the torch-lib export mapping: aten::mul.Scalar and aten::multiply.Scalar. The convert_element_type + scalar literal case is handled by the fix in 0406dc3, and the regression is covered by the x.to(torch.float32) * 1.0 Dynamo export test.

[Justin Chu (justinchuby)]

Copilot can you add the same support for other arithmetic op scalar overloads

[Copilot]

Copilot can you add the same support for other arithmetic op scalar overloads

The other scalar arithmetic overloads are already covered by the same torch-lib pattern in onnxscript/function_libs/torch_lib/ops/core.py: aten::add.Scalar, aten::sub.Scalar, aten::div.Scalar/divide.Scalar/true_divide.Scalar, and the scalar multiply aliases added here. The actual missing registration was the scalar-multiply overload set specifically; the rest of the arithmetic scalar overloads already lower through the standard scalar-to-tensor promotion path.

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.63%. Comparing base (a00b0e0) to head (0406dc3).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
onnxscript/function_libs/torch_lib/ops/core.py	50.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3005      +/-   ##
==========================================
- Coverage   72.63%   72.63%   -0.01%     
==========================================
  Files         265      265              
  Lines       32208    32212       +4     
  Branches     3042     3042              
==========================================
+ Hits        23395    23397       +2     
- Misses       7779     7781       +2     
  Partials     1034     1034              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[Justin Chu (justinchuby)]

Copilot fix lint

[Copilot]

Copilot fix lint

Fixed the lint issue in the regression test and re-ran the repo lint checks. The targeted export regression also passes: d6479b9.

[Promise Emmanuel Oluwadare (promiseeuler)]

While validating the new Scalar overload, I exported and executed four focused cases against this branch: float16 tensor × 1.5, float32 × integer 2, int64 × -3, and bool × true. All four ONNX programs passed onnx.checker and runtime outputs matched PyTorch exactly, including output element types. This gives useful coverage beyond the added float16-to-float32 regression and confirms that materializing the scalar with self.dtype preserves aten::mul.Scalar semantics for the tested real/bool domains. The repository e2e test module itself could not collect in my Python 3.14 environment because that interpreter lacks the optional _lzma module required while importing torchvision; the standalone export/runtime checks avoid that unrelated environment failure.