Claude Code Review Report

I ran Claude Code on Burn to look for potential issues, including logic bugs, copy-paste errors, architecture problems, panics, and similar issues. We use Burn in our company's technology stack, so I wanted to proactively check the code for potential problems rather than discover them later through unexpected behavior and then have to minimize the issue. I've reported similar findings to other projects, such as FEX(https://github.com/FEX-Emu/FEX/issues/5678) , and it looks like this approach has uncovered some genuinely interesting bugs that were subsequently fixed by the authors. The full report is available here: [burn_20260807.html](https://github.com/user-attachments/files/30840797/burn_20260807.html) Here are a few example findings that I'm almost certain are actual bugs: ### CPY_5 `HIGH` **Description:** `From<InterpolateMode> for InterpolateModeIr` silently downgrades `NearestExact` to `Nearest`: ```rust impl From<InterpolateMode> for InterpolateModeIr { fn from(val: InterpolateMode) -> Self { match val { InterpolateMode::Nearest => Self::Nearest, InterpolateMode::NearestExact => Self::Nearest, // <-- wrong variant ... ``` The reverse conversion (`From<InterpolateModeIr> for InterpolateMode`, lines 2033-2043) maps `NearestExact` correctly, and `InterpolateModeIr::NearestExact` exists (line 1871), so this is a paste that was not updated. Every recording backend goes through this conversion: `crates/burn-fusion/src/ops/module.rs:1487` and `crates/burn-router/src/ops/module.rs:963` both build the IR with `options.into()`, and `GridSampleOptionsIr` reuses the same `InterpolateModeIr` conversion (line 2140). Result: `interpolate(..., InterpolateMode::NearestExact)` and `grid_sample_2d` with `NearestExact` produce *floor*-nearest results (a half-pixel/bottom-right shift) when run on `Fusion<...>` or the router/remote backend, while producing exact results on a plain backend. **Locations:** https://github.com/tracel-ai/burn/blob/c2ecf30647ba9187b8e6ad54316895ed986c5234/crates/burn-ir/src/operation.rs#L2051-L2061 **Fix:** Map the variant to itself: ```rust InterpolateMode::NearestExact => Self::NearestExact, ``` Consider adding a round-trip test asserting `InterpolateModeIr::from(m) -> InterpolateMode == m` for every variant of `InterpolateMode`. ### CPY_6 `HIGH` **Description:** `DeformConv2dConfig::init` builds the module with `offset_groups: self.weight_groups` instead of `offset_groups: self.offset_groups`. The configured `offset_groups` value is silently discarded, so `DeformConv2dConfig::new([c_in, c_out], k).with_offset_groups(4)` produces a module that runs `deform_conv2d` with `offset_groups = 1`. Because the offset tensor must have `2 * offset_groups * kernel_h * kernel_w` channels, the wrong option value makes the backend reshape the offsets with the wrong group count. In the ndarray backend this hits `offset.to_shape((groups, kernel_h, kernel_w, 2)).unwrap()` in `deform_im2col` and panics; on other backends it silently reads the wrong offsets. **Locations:** https://github.com/tracel-ai/burn/blob/c2ecf30647ba9187b8e6ad54316895ed986c5234/crates/burn-nn/src/modules/conv/deform_conv2d.rs#L110-L119 **Fix:** ```rust DeformConv2d { ... weight_groups: self.weight_groups, offset_groups: self.offset_groups, // was: self.weight_groups } ``` While there, also validate the offset groups in `init`, since the backend divides the input channels by them: `checks::checks_channels_div_groups(self.channels[0], self.channels[0], self.offset_groups);` ### LOGIC_30 `HIGH` **Description:** `run()` in `importer.py` passes the parsed arguments to `download_and_export` in the wrong order: the function signature is `(name, subset, db_file, token, cache_dir, data_dir, trust_remote_code)` but the call passes `args.data_dir` where `cache_dir` is expected and `args.cache_dir` where `data_dir` is expected. As a result `--cache_dir` is forwarded to `load_dataset(data_dir=...)` and `--data_dir` to `load_dataset(cache_dir=...)`, so `HuggingfaceDatasetLoader::with_huggingface_cache_dir` and `with_huggingface_data_dir` both do the wrong thing (a custom cache dir is interpreted as a dataset sub-path, which usually makes the download fail). **Locations:** https://github.com/tracel-ai/burn/blob/c2ecf30647ba9187b8e6ad54316895ed986c5234/crates/burn-dataset/src/source/huggingface/importer.py#L192-L203 **Fix:** Swap the two arguments: ```python download_and_export( args.name, args.subset, args.file, args.token, args.cache_dir, args.data_dir, args.trust_remote_code, ) ``` Better: pass them by keyword so the ordering cannot drift again.