Fix/converter dtype promotion

[dongwoonhyun]

Description

This PR fixes three dtype-related bugs in converters.

scatter: fix scalar float64 promotion and src dtype mismatch

The scatter converter has 2 bugs that arise under use_explicit_typing:

1. scalars get unconditionally promoted to float64 because of a bare np.ones, which defaults to dtype=np.float64, raising ValueError: TensorRT does not support float64 (double) precision. Fix: replace np.ones with np.full to get the right dtype.
2. Certain TRT ops (e.g., argmax, topk) break the dtype contract and emit INT32 ITensors; downstream consumers like scatter.src then crash because they are promised INT64 inputs but receive INT32. Fix: add a conditional cast in case of dtype mismatch.

preserve bool dtype in promote_trt_tensors_to_same_dtype

promote_trt_tensors_to_same_dtype erroneously promotes operations between (bool, bool) dtypes to int32 because it unconditionally promotes non-floating-point types to int32. This leads to problems when using use_explicit_typing. Fix: explicitly handle the (bool, bool) case to output bool, matching PyTorch's behavior.

scalar coercion: preserve float scalar dtype in integer-typed elementwise ops

When convert_binary_elementwise is called with one Python scalar input and one tensor input, the scalar's dtype is always cast to the tensor's dtype. As a result, int64_tensor * float32_scalar -> int64, which conflicts with PyTorch's type promotion rules, which would be float32. This poses a problem under use_explicit_typing. Fix: Rather than unconditionally casting the scalar to the tensor's dtype, cast it to the dtype that PyTorch's scalar-tensor promotion rules dictate, via torch.result_type.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code follows the style guidelines of this project (You can use the linters)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas and hacks
• I have made corresponding changes to the documentation
• I have added tests to verify my fix or my feature
• New and existing unit tests pass locally with my changes
• I have added the relevant labels to my PR in so that relevant reviewers are notified

[meta-cla]

Hi @dongwoonhyun!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[apbose]

scatter.value still crashes on a float scalar. The fix replaces np.ones(...) with np.full(index_shape_list, src), but np.full still infers dtype purely from the Python scalar's type True to bool, 1 to int64, 2.5 tof loat64 identical to the problem being fixed. Please add a float-scalar test case (e.g. scatter.value(..., 2.5)) that actually exercises this path.
This needs an explicit dtype= argument to np.full, derived from input.dtype

[lanluo-nvidia]

@dongwoonhyun could you please take a look and resolve the comments