Skip to content

Improve dtype error messages by showing user-friendly names#172415

Open
JonSnow1807 wants to merge 1 commit intopytorch:mainfrom
JonSnow1807:improve-dtype-error-messages
Open

Improve dtype error messages by showing user-friendly names#172415
JonSnow1807 wants to merge 1 commit intopytorch:mainfrom
JonSnow1807:improve-dtype-error-messages

Conversation

@JonSnow1807
Copy link
Contributor

Summary

  • Add toDtypeString() function that returns Python-style dtype names
  • Update dispatch error messages to include user-friendly dtype alongside internal name

Before: "addmm_impl_cpu_" not implemented for 'Half'
After: "addmm_impl_cpu_" not implemented for 'Half' (torch.float16)

Fixes #96292

  Add toDtypeString() function that returns Python-style dtype names
  and update dispatch error messages to show both internal and user-friendly names.

  Before: "op" not implemented for 'Half'
  After:  "op" not implemented for 'Half' (torch.float16)

  Fixes pytorch#96292
@JonSnow1807 JonSnow1807 requested a review from janeyx99 as a code owner January 14, 2026 03:18
@pytorch-bot
Copy link

pytorch-bot bot commented Jan 14, 2026

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/172415

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit 95886c2 with merge base 5cb1604 (image):
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

@JonSnow1807
Copy link
Contributor Author

@pytorchbot label "release notes: python_frontend"

@pytorch-bot pytorch-bot bot added the release notes: python_frontend python frontend release notes category label Jan 14, 2026
@soulitzer soulitzer added the triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module label Jan 14, 2026
@vadimkantorov
Copy link
Contributor

vadimkantorov commented Jan 16, 2026

I also wonder if it's possible to include here the device/dispatch key for which the dispatch is happening

@JonSnow1807
Copy link
Contributor Author

Good question! I looked into this. The AT_DISPATCH_* macros only receive the
ScalarType, not the tensor or device - callers pass tensor.scalar_type(),
not the tensor itself.

Adding device info would require changing the macro signature and updating
2,100+ call sites across the codebase - that's a much larger architectural
change.

The current convention is to include device in the NAME parameter (e.g.,
"addmm_impl_cpu_"), which already appears in the error message. This PR
focuses on making the dtype more user-friendly.

Would you be okay keeping this PR focused on the dtype improvement? Device
info could be a separate discussion/RFC if there's interest in changing
the macro API.

@janeyx99
Copy link
Contributor

I don't think this addresses the core ask of the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

open source release notes: python_frontend python frontend release notes category triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Better error message when trying to run fp16 weights on CPU

5 participants