GNNGuard/GRNA use deprecated `torch.range` (unconditional UserWarning; use `torch.arange`)

[xyf5432]

Summary

torch.range is deprecated in favor of torch.arange; it emits a UserWarning on every call, on every torch version (the deprecation predates torch 1.x — there is no silent window), and is scheduled for removal. Three uses across two files — the attack module autogl/module/model/pyg/robust/gnnguard.py and the NAS module autogl/module/nas/space/grna.py — all the identical snippet:

row = torch.range(0, int(adj.shape[0]-1), dtype=torch.int64)
i = torch.stack((row, row), dim=0)
v = torch.ones(adj.shape[0], dtype=torch.float32)
shape = adj.shape
I_n = torch.sparse.FloatTensor(i, v, shape)
return adj + I_n.to(self.device)

1. gnnguard.py:167 — GCN4GNNGuard.add_loop_sparse, on the active training path: called unconditionally from fit at gnnguard.py:210 (adj = self.add_loop_sparse(adj)), so every GCN4GNNGuard.fit() run emits the warning.
2. gnnguard.py:391 — GCN4GNNGuard_attack.add_loop_sparse; currently dead code (its only call site at gnnguard.py:440 is commented out).
3. grna.py:393 — GNNGuard.add_loop_sparse (in the NAS GNNGuard class); currently dead code (no caller anywhere in the repo — GNNGuard.forward calls att_coef, not add_loop_sparse).

setup.py declares no torch version constraint, so any supported torch install hits the warning. Impact: the warning itself; hard failure in warning-as-error environments (-W error::UserWarning, pytest with -W error); AttributeError after removal.

How to reproduce

python -c "
import warnings; warnings.simplefilter('error', UserWarning)
import torch
torch.range(0, 9, dtype=torch.int64)
"

UserWarning: torch.range is deprecated and will be removed in a future release because its usage is inconsistent with the other torch libraries. Use torch.arange instead.

(Verified on torch 2.11.0. The warning is unconditional — reproduce on any installed torch version, e.g. via GCN4GNNGuard().fit(...).)

Request

Replace the three torch.range calls with torch.arange, which has existed since torch 1.0 and requires no version floor:

 # gnnguard.py:167 (GCN4GNNGuard.add_loop_sparse — active in fit)
-        row = torch.range(0, int(adj.shape[0]-1), dtype=torch.int64)
+        row = torch.arange(0, adj.shape[0], dtype=torch.int64)
 # gnnguard.py:391 (GCN4GNNGuard_attack.add_loop_sparse — dead code)
-        row = torch.range(0, int(adj.shape[0]-1), dtype=torch.int64)
+        row = torch.arange(0, adj.shape[0], dtype=torch.int64)
 # nas/space/grna.py:393 (GNNGuard.add_loop_sparse — dead code)
-        row = torch.range(0, int(adj.shape[0]-1), dtype=torch.int64)
+        row = torch.arange(0, adj.shape[0], dtype=torch.int64)

This is a lossless migration for these call sites, for two reasons:

• Closed vs. half-open range: torch.range(0, N-1) (inclusive end) yields 0..N-1, exactly what torch.arange(0, N) (exclusive end) yields — the -1 disappears. Verified element-wise identical on torch 2.11.0.
• Explicit dtype: all three calls pass dtype=torch.int64, so the historical dtype difference (default float32 for torch.range; integer arguments infer int64 for torch.arange since 1.4) is irrelevant here — same values, same dtype, same downstream behavior.

No other torch API change is needed.

References

• PyTorch torch.arange docs: available since torch 1.0; integer arguments default to int64 since torch 1.4.
• Same rule, same fix: kornia/kornia#3380.