noamaanMulla-03/transformers-issues huggingface dataset:
docs: fix typo 'succesful' -> 'successful' in modeling_utils.py
Author: wasim-builds
Pull request: yes

Fixes a few occurrences of the typo 'succesful' in `modeling_utils.py`.

Comments:
Hi maintainers! It looks like the `bandit-check` workflow is failing for this PR because it is triggered by `pull_request_target` and attempts to checkout code from a fork without `allow-unsafe-pr-checkout: true`. This is a known GitHub Actions security mechanism. Could someone take a look at the `.github/workflows/security-gate.yml` configuration on the `main` branch? Once that's resolved (or if you can manually run/approve the check), this minor typo fix should be good to go! Thanks!

Thank you for your contribution 🤗!

## CI Security Gate — automatic approval blocked

This PR was **not** automatically approved for CI because the security gate failed.

**Possible reasons:**
- The PR touches 50 or more files — only PRs with fewer than 50 changed files are automatically approved
- A changed file is outside the allowed directories (`src/`, `tests/`, `docs/`, `utils/`), has a disallowed extension (only `.py`, `.txt`, `.md` permitted outside `tests/` and `docs/`), or is not `.md`/`.yml` inside `docs/`
- A new high-severity security issue was detected in the changed Python files (Bandit check)

See the [workflow run](https://github.com/huggingface/transformers/actions/runs/29474360683) for the exact violations.

A maintainer can review and manually approve CI if a finding is a false positive.

Hi! It looks like the `bandit-check` CI is failing because of the `pull_request_target` fork checkout restriction. Could a maintainer please manually approve the workflow run so the tests can execute? Thank you!

We're trying to avoid these kinds of small PRs right now because of the large volume of agent PRs we're receiving. We'll do a big automated text quality check at some point!
fix: correct dict comprehension syntax in save_pretrained to prevent ValueError
Author: ajayraj30002
Pull request: yes
Labels: name: Code agent slop

# What does this PR do?

Fixes #47333 

There is a small syntax error in `modeling_utils.py` that crashes the `save_pretrained` process for models with offloaded modules.

Currently, `weight_map.update()` is being passed a generator yielding single-key dictionaries, which throws a `ValueError` because `update()` expects a sequence of 2-item tuples. 

Before:
`weight_map.update({k: os.path.basename(shard_file)} for k in shard_state_dict.keys())`

After (moved the closing brace to make it a standard dict comprehension):
`weight_map.update({k: os.path.basename(shard_file) for k in shard_state_dict.keys()})`

## Code Agent Policy

- [x] (First-time contributors only): I confirm that this PR description and code is not written by an LLM or code agent

## Before submitting
- [x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://huggingface.co/docs/transformers/contributing) and the [Pull Request](https://huggingface.co/docs/transformers/pr_checks) checks?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link to it if that's the case.

## Who can review?

@Cyrilvallez @SunMarc (Tagging you as you were mentioned in the original issue!)

Comments:
Thank you for your contribution 🤗!

## CI Security Gate — automatic approval blocked

This PR was **not** automatically approved for CI because the security gate failed.

**Possible reasons:**
- The PR touches 50 or more files — only PRs with fewer than 50 changed files are automatically approved
- A changed file is outside the allowed directories (`src/`, `tests/`, `docs/`, `utils/`), has a disallowed extension (only `.py`, `.txt`, `.md` permitted outside `tests/` and `docs/`), or is not `.md`/`.yml` inside `docs/`
- A new high-severity security issue was detected in the changed Python files (Bandit check)

See the [workflow run](https://github.com/huggingface/transformers/actions/runs/29438030690) for the exact violations.

A maintainer can review and manually approve CI if a finding is a false positive.

#47336 was open already with this fix + the actual fix!
[Model] Add LingBot-Vision Model
Author: IMvision12
Pull request: yes

  Add LingBot-Vision

  What does this PR do?

  Adds LingBot-Vision, a self-supervised ViT vision backbone for dense spatial perception, trained with masked boundary modeling on top of a DINOv3-style architecture (RoPE,
  storage tokens, SwiGLU, LayerScale).

  - Paper: Vision Pretraining for Dense Spatial Perception (https://arxiv.org/abs/2607.05247) (arXiv 2607.05247)
  - Original code/weights: https://github.com/robbyant/lingbot-vision

  
<img width="2304" height="686" alt="lingbot_pca_grid" src="https://github.com/user-attachments/assets/d8167ae0-6ab8-4abc-addf-00b79e6bc8a2" />


Comments:
Thank you for your contribution 🤗!

## CI Security Gate — automatic approval blocked

This PR was **not** automatically approved for CI because the security gate failed.

**Possible reasons:**
- The PR touches 50 or more files — only PRs with fewer than 50 changed files are automatically approved
- A changed file is outside the allowed directories (`src/`, `tests/`, `docs/`, `utils/`), has a disallowed extension (only `.py`, `.txt`, `.md` permitted outside `tests/` and `docs/`), or is not `.md`/`.yml` inside `docs/`
- A new high-severity security issue was detected in the changed Python files (Bandit check)

See the [workflow run](https://github.com/huggingface/transformers/actions/runs/29483476793) for the exact violations.

A maintainer can review and manually approve CI if a finding is a false positive.

**[For maintainers]** Suggested jobs to run (before merge)

run-slow: auto, lingbot_vision

cc @yonigozlan @molbap
Fix OLMo 3 scaled RoPE handling for sliding attention
Author: nurpax
Pull request: yes

## Summary

- Restores OLMo 3 per-layer rotary embeddings after the [RoPE layer-type refactor](https://github.com/huggingface/transformers/pull/39847/files#diff-036fcee5ab04376314d213c74252019c66043aa88b7b65d9c5e55e0b8e90265cL302).  
- Uses default, unscaled RoPE for `sliding_attention` layers and configured RoPE for `full_attention` layers.
- Keeps the current `Gemma2RotaryEmbedding` forward behavior, including returning `cos.to(dtype=x.dtype), sin.to(dtype=x.dtype)`.
- Adds a unit test that catches the regression with a mixed sliding/full attention config and YARN RoPE.

## Context

`Olmo3Model` documents that RoPE scaling is not applied to sliding-window attention layers, but the current implementation computes one configured rotary embedding and passes it to every layer. OLMo 3 needs layer-type-specific RoPE: default RoPE for sliding attention and configured/scaled RoPE for full attention.

## Test plan

- `PYTHONPATH=src python utils/check_modular_conversion.py --files src/transformers/models/olmo3/modular_olmo3.py --num_workers 1`
- `ruff check src/transformers/models/olmo3/modular_olmo3.py src/transformers/models/olmo3/modeling_olmo3.py tests/models/olmo3/test_modeling_olmo3.py`
- `git diff --check`
- `PYTHONPATH=src pytest tests/models/olmo3/test_modeling_olmo3.py -k sliding_attention_uses_default_rope_with_scaled_config -q`

AI assistance was used to prepare this PR. I reviewed the generated diff and am responsible for the change.


Comments:
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: olmo3, olmo_hybrid

Didn't see this PR prev, one sec, let me check the models intended behavior and I will review

Not really how we want to fix it and this is a stale code agent slop, so closing to fix internally

@zucchini-nlp is there an existing issue or PR for the follow-up fix for this issue? I haven't been able to find one

It was fixed @BrownianNotion , you can install from the latest release (https://github.com/huggingface/transformers/pull/46911). Olmo3 now actually applied different RoPE for full and sliding layers

thank you!
Compressed tensors fp8
Author: SunMarc
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47216)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47216)
<!-- ci-dashboard-badge:end -->

# What does this PR do?

Supersedes https://github.com/huggingface/transformers/pull/45699

cc @jiqing-feng if you can have a look at

Comments:
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: compressed_tensors_integration

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_47216). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47216)
**Latest run:** [29034603166:1](https://github.com/huggingface/transformers/actions/runs/29034603166)
**Result:** `failure` | **Jobs:** 15 | **Tests:** 170,180 | **Failures:** 0 | **Duration:** 18h 55m

<!-- ci-dashboard-recap:end -->
fix: allow num_labels property to return None when id2label is unset
Author: SebTardif
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47069)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47069)
<!-- ci-dashboard-badge:end -->

## Summary

`PretrainedConfig.num_labels` was annotated as `-> int` but returned `None` when `id2label` is not set.

## Change

Use `int | None` and document the optional return value.

## Testing

Type annotation aligns with runtime behavior; no logic change.

Comments:
Hopefully fixed now on main

Thank you for your contribution 🤗!

## CI Security Gate — automatic approval blocked

This PR was **not** automatically approved for CI because the security gate failed.

**Possible reasons:**
- The PR touches 50 or more files — only PRs with fewer than 50 changed files are automatically approved
- A changed file is outside the allowed directories (`src/`, `tests/`, `docs/`, `utils/`), has a disallowed extension (only `.py`, `.txt`, `.md` permitted outside `tests/` and `docs/`), or is not `.md`/`.yml` inside `docs/`
- A new high-severity security issue was detected in the changed Python files (Bandit check)

See the [workflow run](https://github.com/huggingface/transformers/actions/runs/29498540277) for the exact violations.

A maintainer can review and manually approve CI if a finding is a false positive.

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47069)
**Latest run:** [29153675305:2](https://github.com/huggingface/transformers/actions/runs/29498541011)
**Result:** `success` | **Jobs:** 15 | **Tests:** 170,747 | **Failures:** 0 | **Duration:** 5h 1m

<!-- ci-dashboard-recap:end -->

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_47069). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
ci: Handle missing summaries in collated reports
Author: tarekziade
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47368)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47368)
<!-- ci-dashboard-badge:end -->

# What does this PR do?

Make sure we always produce a summary short. 

So the missing report artifact directory is:

  single-gpu_run_models_gpu_utils_test_reports

A July 13 example is:

Run: https://github.com/huggingface/transformers/actions/runs/29221731474

The codegen model did not produce the summary_short.txt file

  https://github.com/huggingface/transformers/actions/runs/29221731474/job/86728608989

Failing collated job:
https://github.com/huggingface/transformers/actions/runs/29221731474/job/86746888790

Missing file:

single-gpu_run_models_gpu_models_codegen_test_reports/summary_short.txt

CodeGen did not produce summary_short.txt because pytest never reached pytest_terminal_summary.

Evidence from the job log:

- The job was still running tests:

    tests/models/codegen/
    test_tokenization_codegen.py::CodeGenTokenizationTest::test_internal_consistency

- Immediately after that, GitHub moved to:

    Run cp /transformers/test_outputs.txt ...

- There is no pytest final summary, no short test summary, no stats footer, and no  COMMAND_EXIT_CODE.

- The artifact upload says only 3 files existed:
- 
    captured_info.txt
    dummy.txt
    test_outputs.txt

  summary_short.txt is only written at the end of pytest, via conftest.py ->
  pytest_terminal_summary_main() -> tr.short_test_summary(). Since the pytest process was
  interrupted/stopped before terminal summary, that file was never created.

  The weird part is the wrapper step was marked success. The workflow expects script -q -c "...
  pytest ..." to append a COMMAND_EXIT_CODE, then it extracts that and exits. In this job that tail
  logic apparently never ran, yet the step concluded success. So the likely root is not a normal
  CodeGen test failure; it is the custom runner/container wrapper interrupting or ending the pytest
  command mid-run in a way GitHub treated as success.

  There was a real CodeGen failure earlier in the partial output (test_codegen_sample), but a normal
  pytest failure would still run terminal summary and create summary_short.txt. Here pytest did not
  finish.

Comments:
<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47368)
**Latest run:** [29501336447](https://github.com/huggingface/transformers/actions/runs/29501336447)
**Result:** `success` | Grafana metrics are not available yet.

<!-- ci-dashboard-recap:end -->

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_47368). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
[TimesFM 2.5]:`window_size` argument raises `AttributeError`
Author: kanenorman
Pull request: no
Labels: name: bug

### System Info

- `transformers` version: 5.13.0.dev0
- Platform: macOS-26.5.1-arm64-arm-64bit
- Python version: 3.11.3
- Huggingface_hub version: 1.20.1
- Safetensors version: 0.8.0
- Accelerate version: 1.14.0
- Accelerate config:    not found
- DeepSpeed version: not installed
- PyTorch version (accelerator?): 2.12.1 (NA)
- Using distributed or parallel set-up in script?: No

### Who can help?

The model behaves correctly when `window_size=None` (default). Setting `window_size` to any value instead results in an `AttributeError`.

Happy to submit a fix.

@vasqu 
@kashif 

### Information

- [x] The official example scripts
- [x] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [x] My own task or dataset (give details below)

### Reproduction

Example script based on the documentation [example](https://huggingface.co/docs/transformers/en/model_doc/timesfm2_5#usage-example)
```python
import torch

from transformers import TimesFm2_5ModelForPrediction


model = TimesFm2_5ModelForPrediction.from_pretrained(
    "google/timesfm-2.5-200m-transformers",
    device_map="auto",
)

forecast_input_tensor = [
    torch.sin(torch.linspace(0, 20, 100, dtype=torch.float32, device=model.device)),
    torch.sin(torch.linspace(0, 20, 200, dtype=torch.float32, device=model.device)),
    torch.sin(torch.linspace(0, 20, 400, dtype=torch.float32, device=model.device)),
]

with torch.no_grad():
    outputs = model(past_values=forecast_input_tensor, window_size=5)
```

Error
```
Traceback (most recent call last):
  File "/transformers/bug.py", line 18, in <module>
    outputs = model(past_values=forecast_input_tensor, window_size=5)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/transformers/.venv/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1778, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/transformers/.venv/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1789, in _call_impl
    return forward_call(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/transformers/src/transformers/utils/generic.py", line 907, in wrapper
    output = func(self, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/transformers/src/transformers/models/timesfm2_5/modeling_timesfm2_5.py", line 780, in forward
    new_inputs.extend(self._timesfm_moving_average(ts, window_size))
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/transformers/.venv/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1967, in __getattr__
    raise AttributeError(
AttributeError: 'TimesFm2_5ModelForPrediction' object has no attribute '_timesfm_moving_average'. Did you mean: '_timesfm2_5_moving_average'?
```

### Expected behavior

Expect return `TimesFm2_5OutputForPrediction`

Comments:
Hi @kashif! I noticed you self-assigned this. Are you still planning to work on it, or would you be open to me opening a PR?

Fix is in #47363
from_config(dtype=...) builds weights in the requested dtype but leaves model.config.dtype stale
Author: qflen
Pull request: no

### System Info

- `transformers` version: 5.10.0.dev0 (also reproduces on current `main`)
- Platform: macOS-26.1-arm64-arm-64bit
- Python version: 3.11.15
- Huggingface_hub version: 1.14.0
- Safetensors version: 0.7.0
- Accelerate version: 1.13.0
- PyTorch version (accelerator?): 2.11.0 (NA)
- Using distributed or parallel set-up in script?: No

This is a pure model-loading logic bug, not hardware-dependent.

### Who can help?

@Cyrilvallez @zucchini-nlp 

### Information

- [ ] The official example scripts
- [X] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [X] My own task or dataset (give details below)

### Reproduction

`from_config(dtype=X)` builds the weights in `X` but never writes `X` to the top-level `config.dtype`, so `model.dtype` and `model.config.dtype` disagree:

```python
import torch
from transformers import AutoModelForCausalLM, LlamaConfig

cfg = LlamaConfig(vocab_size=32, hidden_size=8, intermediate_size=16,
                  num_hidden_layers=1, num_attention_heads=2)
model = AutoModelForCausalLM.from_config(cfg, dtype=torch.float16)
print(model.dtype)         # torch.float16  <- weights honored
print(model.config.dtype)  # None           <- stale, expected torch.float16
```

In `_from_config` the resolved `dtype` is written to every sub-config but not to the top-level config, so for a leaf config (no `sub_configs`) the loop is a no-op and `config.dtype` is never updated:

https://github.com/huggingface/transformers/blob/d6a82ba896fcc59e6c40af95cbbd167dcf736e2f/src/transformers/modeling_utils.py#L1570-L1574

### Expected behavior

After `from_config(dtype=X)`, `model.config.dtype == X`, matching what `from_pretrained` already does.

The core fix is one line (`config.dtype = dtype` before the loop), but it is not a clean one-liner: it is a global `_from_config` change that breaks 4 tests in `tests/utils/test_modeling_utils.py` (`test_model_from_config_dtype{,_str,_composite}`, `test_model_from_pretrained_dtype`) and needs to handle the deprecated per-sub-config dtype-dict path (where `dtype` is a `dict`). 

Surfaced while investigating #46459.


Comments:
Yep, this is valid, have to set `config.dtype = main_dtype` as well

Do you want to add  this one-liner fix in above PR?

@zucchini-nlp I added it to the existing PR.

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.
Fix dtype-sensitive vision position ids for Idefics/SmolVLM
Author: Gideon0805
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47133)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47133)
<!-- ci-dashboard-badge:end -->

## What changed

  This updates the vision position id computation used by Idefics2, Idefics3, and SmolVLM to use integer arithmetic instead of floating point bucketization.

  ## Why

  The previous implementation computed fractional coordinates, cast them to `pixel_values.dtype`, and then used `torch.bucketize`. This made the generated position ids dtype-
  sensitive.

  For a full 32x32 patch grid, `float32` could map the last row/column to bucket 30 because of the `1 - 1e-6` clamp, producing max position id 990. In `float16`/`bfloat16`, the
  factor rounds to 1.0, producing the expected max position id 1023.

  The new integer mapping preserves the intended bucket assignment while making it independent of pixel dtype.

  ## Tests

  - `python -m py_compile src/transformers/models/idefics2/modeling_idefics2.py src/transformers/models/idefics3/modeling_idefics3.py src/transformers/models/smolvlm/
  modeling_smolvlm.py tests/models/smolvlm/test_modeling_smolvlm.py`
  - `git diff --check`
  - Added `test_vision_position_ids_are_dtype_invariant`

Comments:
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: idefics2, idefics3, smolvlm

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47133)
**Latest run:** [28857034892](https://github.com/huggingface/transformers/actions/runs/28857034892)
**Result:** `success` | Grafana metrics are not available yet.

<!-- ci-dashboard-recap:end -->

Hmmn, I think this bug is real, but if the model was trained with the original slightly buggy bucketing then we probably don't want to change it, as this would cause distribution drift and probably worsen the output from existing checkpoints! cc @zucchini-nlp @molbap

> Yeah, Matt is right, @Gideon0805 did you check the generation output/stumble upon IndexError/etc or is this purely theoretical bug?
> 
> If it is just theoretically a bug, I agree that we better keep the "buggy" original code

If we use `dtype=bf16`, the position IDs become “correct”, but the cosine similarity of the output compared with the fp32 result is different.

I agree that we should keep the original “buggy” behavior to match the pretrained weights. However, we may need a fix for the bf16 dtype case, because when the model runs inference in bf16, the output may be incorrect.


> the cosine similarity of the output compared with the fp32 result is different

It should be fine, as different precisions entail that the output will be different at the end