c10::SourceLocation / AutogradState use C++20-only syntax with no C++17 fallback, causing misleading errors under nvcc -std=c++17

### 🐛 Describe the bug

Description:

## 🐛 Describe the bug

`c10/util/StringUtil.h` uses a C++20 designated initializer:

```cpp
// c10/util/StringUtil.h, line 165-170
static constexpr SourceLocation current(
const char* file = __builtin_FILE(),
const char* function = __builtin_FUNCTION(),
const std::uint_least32_t line = __builtin_LINE()) noexcept {
return {.function = function, .file = file, .line = line};
}

and c10/core/AutogradState.h uses C++20 bit-field default member initializers:

// c10/core/AutogradState.h, line 85-90
bool grad_mode_ : 1;
bool inference_mode_ : 1;
bool fw_grad_mode_ : 1;
bool multithreading_enabled_ : 1;
bool view_replay_enabled_ : 1 = false;
bool grad_layout_enforcement_enabled_ : 1 = true;

Both constructs are illegal under -std=c++17. This isn't hit in the normal PyTorch-provided build, since torch/utils/cpp_extension.py forces /std:c++20 for the MSVC host-compiler invocation on Windows (cflags = common_cflags + ['/std:c++20'] + extra_cflags) — but nvcc parses .cu files with its own C++ frontend using whatever -std= flag the downstream build script passes to nvcc directly, independent of the host-compiler flag torch injects. Any project that explicitly sets -std=c++17 for nvcc (not unusual — e.g. SageAttention (https://github.com/thu-ml/SageAttention)'s setup.py hardcodes it) hits a parse failure at these two headers.

Worse, the resulting errors are actively misleading and give no indication of the real cause:

c10/util/StringUtil.h(169): error: expected an expression
c10/core/AutogradState.h(89): error: data member initializer is not allowed
c10/core/AutogradState.h(90): error: data member initializer is not allowed

In our case this parse failure also appeared to cascade into confusing, spurious-looking diagnostics elsewhere in the same translation unit, making the actual root cause hard to track down.

Also worth noting: forcing nvcc to -std=c++20 (matching what these headers actually require) is not a safe workaround either — on this environment it causes nvcc's internal cudafe++ to crash outright ('cudafe++' died with status 0xC0000409) on both CUDA 13.0 and CUDA 13.3, so a C++17-compatible header is really the only clean path for this class of build.

Repro

Compile any .cu file that includes (or otherwise transitively includes c10/util/StringUtil.h) with nvcc's frontend explicitly set to -std=c++17:

nvcc -std=c++17 -c some_file.cu ...

Suggested fix

Either:
- Gate the C++20-only syntax behind #if __cplusplus >= 202002L (or the MSVC _MSVC_LANG equivalent) with a C++17-compatible fallback — plain positional aggregate initialization for SourceLocation; move the bit-field defaults into AutogradState's constructor member-initializer list instead of in-class, or
- If C++20 is now a hard requirement for these headers, fail fast with a clear #error naming the actual requirement, rather than letting downstream projects hit an opaque parse error in an unrelated-looking spot.

Versions

- PyTorch: 2.13.0+cu130 (git cf30153c4c131c8164ee7798e5022d810682e2cb)
- CUDA: 13.0
- Python: 3.13.14
- OS: Windows 11
- nvcc invoked with -std=c++17 (downstream project's explicit flag, not a torch default)
- Repro'd with both MSVC 19.44 (VS2022 BuildTools 14.44.35207) and MSVC 19.29 (VS2019 14.29.30133) as host compiler — confirms it's an nvcc-frontend/-std= issue, not MSVC-version-specific

### Versions

(comfy) D:\comfyui\ComfyUI\custom_nodes>curl -sL https://raw.githubusercontent.com/pytorch/pytorch/main/torch/utils/collect_env.py | python
Collecting environment information...
PyTorch version: 2.13.0+cu130
Is debug build: False
CUDA used to build PyTorch: 13.0
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 11 Pro (10.0.26200 64-bit)
GCC version: (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders, r8) 13.2.0
Clang version: Could not collect
CMake version: version 4.4.2
Libc version: N/A

Python version: 3.13.14 | packaged by Anaconda, Inc. | (main, Jul 9 2026, 14:26:41) [MSC v.1942 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-11-10.0.26200-SP0
Is CUDA available: True
CUDA runtime version: 13.3.73
CUDA_MODULE_LOADING set to:
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 5070 Ti
Nvidia driver version: 595.97
cuDNN version: Could not collect
Is XPU available: False
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: False
Caching allocator config: N/A

CPU:
Name: AMD Ryzen 9 9900X 12-Core Processor
Manufacturer: AuthenticAMD
Family: 107
Architecture: 9
ProcessorType: 3
DeviceID: CPU0
CurrentClockSpeed: 4400
MaxClockSpeed: 4400
L2CacheSize: 12288
L2CacheSpeed: None
Revision: 17408

Versions of relevant libraries:
[pip3] numpy==2.4.4
[pip3] onnxruntime==1.28.0
[pip3] open_clip_torch==3.3.0
[pip3] optree==0.19.1
[pip3] pytorch-lightning==2.6.5
[pip3] rotary-embedding-torch==0.9.1
[pip3] torch==2.13.0+cu130
[pip3] torch-complex==0.4.4
[pip3] torchaudio==2.11.0+cu130
[pip3] torchcodec==0.16.0
[pip3] torchmetrics==1.9.0
[pip3] torchsde==0.2.6
[pip3] torchvision==0.28.0+cu130
[pip3] triton-windows==3.7.1.post27
[conda] numpy 2.4.4 pypi_0 pypi
[conda] open-clip-torch 3.3.0 pypi_0 pypi
[conda] optree 0.19.1 pypi_0 pypi
[conda] pytorch-lightning 2.6.5 pypi_0 pypi
[conda] rotary-embedding-torch 0.9.1 pypi_0 pypi
[conda] torch 2.13.0+cu130 pypi_0 pypi
[conda] torch-complex 0.4.4 pypi_0 pypi
[conda] torchaudio 2.11.0+cu130 pypi_0 pypi
[conda] torchcodec 0.16.0 pypi_0 pypi
[conda] torchmetrics 1.9.0 pypi_0 pypi
[conda] torchsde 0.2.6 pypi_0 pypi
[conda] torchvision 0.28.0+cu130 pypi_0 pypi
[conda] triton-windows 3.7.1.post27 pypi_0 pypi

(comfy) D:\comfyui\ComfyUI\custom_nodes>

cc @malfet @zklaus @janeyx99

Start with the reported constructs in c10/util/StringUtil.h lines 165-170 and c10/core/AutogradState.h lines 85-90, then reproduce the failure with nvcc -std=c++17 on a .cu file including torch/extension.h. Check that both headers parse under C++17 and that the resulting build no longer emits the reported errors, while preserving the existing C++20 behavior where applicable.

Written by the indexing model from the issue text.