Repository: pytorch
Issue: [JIT] torch.load(model) fails for Unicode Variable Names.
Labels: oncall: jit

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

Jit-compiled models with unicode variable names can be saved, but not loaded.

## To Reproduce

```python
import torch
from torch import nn, jit, Tensor

class WithoutUnicode(nn.Module):
    def forward(self, delta_t: Tensor) -> Tensor:
        return delta_t

# non-jitted
model = WithoutUnicode()
torch.save(model, "WithoutUnicode.pt")
torch.load("WithoutUnicode.pt")   # <- Succeeds ✔


model = jit.script(WithoutUnicode())
jit.save(model, "WithoutUnicode.pt")
jit.load("WithoutUnicode.pt")   # <- Succeeds ✔

class WithUnicode(nn.Module):
    def forward(self, Δt: Tensor) -> Tensor:
        return Δt

model = WithUnicode()
torch.save(model, "WithUnicode.pt")
torch.load("WithUnicode.pt")  # <- Succeeds ✔
    
model = jit.script(WithUnicode())
jit.save(model, "WithUnicode.pt")
jit.load("WithUnicode.pt")  # <- Fails ↯
```

The returned error is not descriptive:

```python
    159     cu = torch._C.CompilationUnit()
    160     if isinstance(f, str) or isinstance(f, pathlib.Path):
--> 161         cpp_module = torch._C.import_ir_module(cu, str(f), map_location, _extra_files)
    162     else:
    163         cpp_module = torch._C.import_ir_module_from_buffer(

RuntimeError: 
```

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

<!-- A clear and concise description of what you expected to happen. -->

If a variable name is legal in python, it should be legal in pytorch.
Alternatively, `torch.save` should already disallow saving and throw a descriptive error message, if illegal variable names are present.

## Environment

<details><summary>Collecting environment information...</summary>
```
PyTorch version: 1.9.1
Is debug build: False
CUDA used to build PyTorch: 11.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.3 LTS (x86_64)
GCC version: (GCC) 9.4.0
Clang version: 10.0.0-4ubuntu1 
CMake version: version 3.16.3
Libc version: glibc-2.31

Python version: 3.9.7 | packaged by conda-forge | (default, Sep 14 2021, 01:17:55)  [GCC 9.4.0] (64-bit runtime)
Python platform: Linux-5.11.0-34-generic-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: 11.4.120
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 3090
Nvidia driver version: 470.57.02
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.2.4
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.2.4
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.2.4
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.2.4
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.2.4
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.2.4
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.2.4
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn.so.8.2.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.2.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.2.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.2.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.2.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.2.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.2.1
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn.so.8.2.1
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.2.1
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.2.1
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.2.1
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.2.1
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.2.1
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.2.1
/usr/local/cuda-11.3/targets/x86_64-linux/lib/libcudnn.so.8.2.1
/usr/local/cuda-11.3/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.2.1
/usr/local/cuda-11.3/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.2.1
/usr/local/cuda-11.3/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.2.1
/usr/local/cuda-11.3/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.2.1
/usr/local/cuda-11.3/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.2.1
/usr/local/cuda-11.3/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.2.1
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn.so.8.2.2
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.2.2
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.2.2
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.2.2
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.2.2
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.2.2
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.2.2
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] mypy==0.910
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.21.2
[pip3] numpydoc==1.1.0
[pip3] numpyro==0.7.2
[pip3] pytorch-forecasting==0.9.0
[pip3] pytorch-lightning==1.4.8
[pip3] torch==1.9.1
[pip3] torchaudio==0.9.0a0+a85b239
[pip3] torchdiffeq==0.2.2
[pip3] torchinfo==1.5.3
[pip3] torchmetrics==0.5.1
[pip3] torchtext==0.10.1
[pip3] torchvision==0.2.2
[conda] blas                      2.108                       mkl    conda-forge
[conda] blas-devel                3.9.0                     8_mkl    conda-forge
[conda] cudatoolkit               11.1.74              h6bb024c_0    nvidia
[conda] libblas                   3.9.0                     8_mkl    conda-forge
[conda] libcblas                  3.9.0                     8_mkl    conda-forge
[conda] liblapack                 3.9.0                     8_mkl    conda-forge
[conda] liblapacke                3.9.0                     8_mkl    conda-forge
[conda] mkl                       2020.4             h726a3e6_304    conda-forge
[conda] mkl-devel                 2020.4             ha770c72_305    conda-forge
[conda] mkl-include               2020.4             h726a3e6_304    conda-forge
[conda] mkl-service               2.3.0            py39h07f9747_2    conda-forge
[conda] mypy                      0.910            py39h3811e60_0    conda-forge
[conda] mypy_extensions           0.4.3            py39hf3d152e_3    conda-forge
[conda] numpy                     1.21.2           py39hdbf815f_0    conda-forge
[conda] numpydoc                  1.1.0                      py_1    conda-forge
[conda] numpyro                   0.7.2              pyhd8ed1ab_0    conda-forge
[conda] pytorch                   1.9.1           py3.9_cuda11.1_cudnn8.0.5_0    pytorch
[conda] pytorch-forecasting       0.9.0              pyhd8ed1ab_0    conda-forge
[conda] pytorch-lightning         1.4.8              pyhd8ed1ab_0    conda-forge
[conda] torchaudio                0.9.1                      py39    pytorch
[conda] torchdiffeq               0.2.2              pyhd8ed1ab_0    conda-forge
[conda] torchinfo                 1.5.3              pyhd8ed1ab_0    conda-forge
[conda] torchmetrics              0.5.1              pyhd8ed1ab_0    conda-forge
[conda] torchtext                 0.10.1                     py39    pytorch
[conda] torchvision               0.2.2                      py_3    pytorch
​```
</details>

## Additional context

<!-- Add any other context about the problem here. -->

Using any (jitted) model with unicode variable names already works fine, it is really just the `jit.load` part that fails.

I would really appreciate if Unicode was supported, because it allows writing code that is closer to mathematical notation. E.g. if a paper calls a parameter `Δt`, then, in my opinion, using `Δt` as a variable name is nicer than the more verbose `delta_t`.

This is especially the case when comparing code side-by-side with pseudocode from a paper.