New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Properly serialize types that only appear at function input #47775
Conversation
When serializing graphs, we check every node for named types referenced, so that we can register them as dependencies. We were skipping this check for the graph inputs themselves. Since types used at input are almost always used somewhere in the graph, we never noticed this gap until a user reported an issue with NamedTuples. [ghstack-poisoned]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about at the output? I can sneakily construct a counterexample like so:
import torch
from typing import NamedTuple, Optional
class Point(NamedTuple):
x : int
y : int
class Foo(torch.nn.Module):
def __init__(self):
super().__init__()
def forward(self) -> Optional[Point]:
return None
script = torch.jit.script(Foo())
torch.jit.save(script, 'foo.zip')
torch.jit.load('foo.zip')
"""
RuntimeError:
Unknown type name '__torch__.Point':
Serialized File "code/__torch__.py", line 5
__buffers__ = []
training : bool
def forward(self: __torch__.Foo) -> Optional[__torch__.Point]:
~~~~~~~~~~~~~~~ <--- HERE
return None
"""
When serializing graphs, we check every node for named types referenced, so that we can register them as dependencies. We were skipping this check for the graph inputs themselves. Since types used at input are almost always used somewhere in the graph, we never noticed this gap until a user reported an issue with NamedTuples. Differential Revision: [D24896289](https://our.internmc.facebook.com/intern/diff/D24896289) [ghstack-poisoned]
💊 CI failures summary and remediationsAs of commit b540718 (more details on the Dr. CI page):
🚧 2 fixed upstream failures:These were probably caused by upstream breakages that were already fixed.
Please rebase on the
|
When serializing graphs, we check every node for named types referenced, so that we can register them as dependencies. We were skipping this check for the graph inputs themselves. Since types used at input are almost always used somewhere in the graph, we never noticed this gap until a user reported an issue with NamedTuples. Differential Revision: [D24896289](https://our.internmc.facebook.com/intern/diff/D24896289) [ghstack-poisoned]
When serializing graphs, we check every node for named types referenced, so that we can register them as dependencies. We were skipping this check for the graph inputs themselves. Since types used at input are almost always used somewhere in the graph, we never noticed this gap until a user reported an issue with NamedTuples. ghstack-source-id: 50b22f2c7b1f1a39c374ab125e3981a06bf9b2f7 Pull Request resolved: #47775
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stack from ghstack:
When serializing graphs, we check every node for named types referenced,
so that we can register them as dependencies. We were skipping this
check for the graph inputs themselves. Since types used at input are
almost always used somewhere in the graph, we never noticed this gap
until a user reported an issue with NamedTuples.
Differential Revision: D24896289