Commit Graph

12 Commits

Author SHA1 Message Date
Zachary DeVito
eb9000be4e always use the closure to resolve variable names (#27515)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/27515

Resoving variable names using the local activation frames does not work
when using recursive scripting, but our current code tries to do it
(incorrectly) anyway. The reason it works is only because the script
call is in the same local frame as the definition. This will not be
true in practice and makes it seem like the API works in more cases
than it really does. This forces us to always use closure-based annotations,
documents it, and it fixes the tests so that they still pass.

Test Plan: Imported from OSS

Differential Revision: D17803403

Pulled By: zdevito

fbshipit-source-id: e172559c655b05f0acf96c34f5bdc849f4e09ce2
2019-10-09 12:16:15 -07:00
Elias Ellison
1f2fa8d4d8 Make jit dicts ordered (#26465)
Summary:
Makes c10::Dict Ordered and bins binds the OrderedDict() and dict() constructor into torchscript. For the case of the empty constructor dict() i typed it as [str, Tensor] because:
• we're almost dropping support for python 2, at which point all dicts are ordered
• then it's more conventional to write x : Dict[int, int] = {} which is already supported
• It is possible to construct an arbitrarily typed empty OrderedDict through
OrderedDict(torch.jit.annotate(List[Tuple[key, value]], [])

We could consider dropping the no inputs aten::dict constructor since then the types would be more explicit.

This replaces https://github.com/pytorch/pytorch/issues/26170 and https://github.com/pytorch/pytorch/pull/26372 b/c ghstack was poisioned and i had to resubmit
Pull Request resolved: https://github.com/pytorch/pytorch/pull/26465

Differential Revision: D17481604

Pulled By: eellison

fbshipit-source-id: d2d49795a518c3489881afac45d070e5262c5849
2019-09-19 15:09:02 -07:00
Zachary DeVito
121839b2f8 Fix bugs in assignment to optionals (#25059)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/25059

This fixes the cases where a type annotated with optional cannot
be conditionally assigned to none:

```
x : Optional[int] = 4
if ...:
 x = None
```

Test Plan: Imported from OSS

Differential Revision: D16975166

Pulled By: zdevito

fbshipit-source-id: 5a7a81224d08b9447e1f4d957fcd882091e02f32
2019-08-26 13:47:54 -07:00
Elias Ellison
ab38059bc7 fix annotated assignment (#25094)
Summary:
Fixing parsing for annotated assignment
`List[int] a = []`.

See https://github.com/pytorch/pytorch/pull/24989/files?file-filters%5B%5D=.py for changes to the test_jit_py3 & run_test files.

follow up to https://github.com/pytorch/pytorch/pull/24477 and fix for https://github.com/pytorch/pytorch/issues/25086
Pull Request resolved: https://github.com/pytorch/pytorch/pull/25094

Differential Revision: D16985016

Pulled By: eellison

fbshipit-source-id: 6be1363f2503303b96bd2e6a9f188ad72441f4eb
2019-08-23 13:14:38 -07:00
Zachary DeVito
f9f5af0ed7 Revert D16949314: [jit] Fix bugs in assignment to optionals
Test Plan: revert-hammer

Differential Revision:
D16949314

Original commit changeset: 7f63d88b30a3

fbshipit-source-id: d1f00de2ad9c3484b731ad1b24205ca60024355d
2019-08-22 16:50:48 -07:00
Zachary DeVito
bb79b61ce7 Fix bugs in assignment to optionals (#24989)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/24989

This fixes the cases where a type annotated with optional cannot
be conditionally assigned to none:

```
x : Optional[int] = 4
if ...:
 x = None
```

Test Plan: Imported from OSS

Differential Revision: D16949314

Pulled By: zdevito

fbshipit-source-id: 7f63d88b30a3f5b024c2a539aa74967c9202af00
2019-08-22 16:27:46 -07:00
Zachary DeVito
ee898bffc3 fix IR parsing bug
Summary: Pull Request resolved: https://github.com/pytorch/pytorch/pull/24294

Test Plan: Imported from OSS

Differential Revision: D16797690

Pulled By: zdevito

fbshipit-source-id: f89664dc7da3547c316aa5875bf67bef672430c2
2019-08-16 10:10:42 -07:00
davidriazati
fad3031b5c Fix type hints for None constants (#23029)
Summary:
The type hint was being ignored when emitting `None` constants, this also de-dups some testing code
](https://our.intern.facebook.com/intern/diff/16364572/)
Pull Request resolved: https://github.com/pytorch/pytorch/pull/23029

Pulled By: driazati

Differential Revision: D16364572

fbshipit-source-id: 64f3abd3e37ee49c209480a85ed4f1b8802e5d93
2019-07-22 11:55:05 -07:00
James Reed
dd046bef8d NamedTuple serialization (#21839)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/21839
ghimport-source-id: b9d82018fbf26b22d58cad3a033cbfe4e879a8fe

Test Plan: Imported from OSS

Reviewed By: zdevito

Differential Revision: D15860002

Pulled By: jamesr66a

fbshipit-source-id: 0fc97c4adefa9ae4937f21179c7afa817f4099e5
2019-06-19 10:43:55 -07:00
James Reed
74104f383e Some small fixes for NamedTuple (#21813)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/21813
ghimport-source-id: a1edca8ad0384a9e493ef2f3b0aa5005a668a8f3

Test Plan: Imported from OSS

Reviewed By: zdevito

Differential Revision: D15860005

Pulled By: jamesr66a

fbshipit-source-id: 4a43432d2dacebde1a676a93ac57f675db857154
2019-06-19 10:43:43 -07:00
James Reed
4bcc72fe95 Support for NamedTuple (#21428)
Summary:
Resolves https://github.com/pytorch/lockdown/issues/18

This implements NamedTuple by taking advantage of the existing `names` field in `TupleType`.

TODO: This currently doesn't retain the NamedTuple-ness through serialization. Discussed with suo offline, we can probably make a way to define an anonymous NamedTuple in script (e.g. `NamedTuple('Foo', [('a', int), ('b', float), ('c', List[float])])` and serialize that
TODO: implement support for calling the constructor with kwargs
Pull Request resolved: https://github.com/pytorch/pytorch/pull/21428

Differential Revision: D15741564

Pulled By: jamesr66a

fbshipit-source-id: c077cbcea1880675ca6deb340a9ec78f824a136c
2019-06-14 16:45:56 -07:00
James Reed
fe39602451 Support for rudimentary f-strings (#21037)
Summary:
Resolves https://github.com/pytorch/lockdown/issues/51

This adds support for converting simple f-string literals to calls to `string.format()`. It does not support conversion specifiers or format strings.

This also does not support the string parser frontend, since that implementation would be more involved and likely would require modifying our TorchScript AST
Pull Request resolved: https://github.com/pytorch/pytorch/pull/21037

Reviewed By: zdevito

Differential Revision: D15541183

Pulled By: jamesr66a

fbshipit-source-id: ae9df85e73f646d7219c1349f5b7683becbcef20
2019-05-30 15:50:45 -07:00