noamaanMulla-03/transformers-issues huggingface dataset:
keys_to_ignore_at_inference -> output_keys_to_ignore_at_inference
Author: sgugger
Pull request: yes

# What does this PR do?

@patrickvonplaten mentioned in #8633 he was not happy with a name I picked, so I changed it.

Comments:
Not sure this is really worth the hassle then.

> Not sure this is really worth the hassle then.

Agree, let's leave it. It's just a personal cosmetic change, so not worth the change.
Tokenizers - move from hardcoded configs and models to fully hosted
Author: thomwolf
Pull request: yes
Labels: name: wontfix

# What does this PR do?

Fixes #8125 #8117 

Tokenizer checkpoint files are now handled the same way than model files.

Also:
- add a `tokenizer_class_name` field in the tokenization config file `tokenizer_config.json`. This field is used when possible by `AutoTokenizer` to disambiguate the tokenizer to instantiate
- concurrently configuration and vocabulary files are updated on the relevant model repo in the hub to wake them independant from the code-base.
- the max length of the models was always the same for all the variante in an architecture. Consequently we simply the `max_model_input_sizes` attribute to make it a single integer instead of a mapping from string (model names) to integers. 

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [ ] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [ ] 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.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/master/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/master/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors which may be interested in your PR.

<!-- Your PR will be replied to more quickly if you can figure out the right person to tag with @

 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

 albert, bert, XLM: @LysandreJik
 GPT2: @LysandreJik, @patrickvonplaten
 tokenizers: @mfuntowicz
 Trainer: @sgugger
 Benchmarks: @patrickvonplaten
 Model Cards: @julien-c
 examples/distillation: @VictorSanh
 nlp datasets: [different repo](https://github.com/huggingface/nlp)
 rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)
 Text Generation: @patrickvonplaten, @TevenLeScao
 Blenderbot, Bart, Marian, Pegasus: @patrickvonplaten
 T5: @patrickvonplaten
 Rag: @patrickvonplaten, @lhoestq
 EncoderDecoder: @patrickvonplaten
 Longformer, Reformer: @patrickvonplaten
 TransfoXL, XLNet: @TevenLeScao, @patrickvonplaten
 examples/seq2seq: @patil-suraj
 examples/bert-loses-patience: @JetRunner
 tensorflow: @jplu
 examples/token-classification: @stefan-it
 documentation: @sgugger
 FSTM: @stas00
 -->


Comments:
This issue has been automatically marked as stale and been closed because it has not had recent activity. Thank you for your contributions.

If you think this still needs to be addressed please comment on this thread.
Bump notebook from 6.1.4 to 6.1.5 in /examples/lxmert
Author: dependabot[bot]
Pull request: yes
Labels: name: wontfix

Bumps [notebook](https://github.com/jupyter/jupyterhub) from 6.1.4 to 6.1.5.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/jupyter/jupyterhub/commits">compare view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=notebook&package-manager=pip&previous-version=6.1.4&new-version=6.1.5)](https://docs.github.com/en/github/managing-security-vulnerabilities/configuring-github-dependabot-security-updates)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/huggingface/transformers/network/alerts).

</details>

Comments:
This issue has been automatically marked as stale and been closed because it has not had recent activity. Thank you for your contributions.

If you think this still needs to be addressed please comment on this thread.
Make BART more ONNX friendly
Author: mfuntowicz
Pull request: yes
Labels: name: wontfix

**Major concerns:** 
1. ONNX complains about Python raw integer usage.
2. ONNX doesn't support boolean indexing with something else than vector. The code was using 2D Tensor indices (batch, token). 

**PR workarounds:**
1. Remove the call to `len(..)` and prefer the use of `.size(-1)`
2. Attempt to index the output tensors to retrieve only the **last** EOS token over the sequence axis through `.index_select(..)`

Comments:
I believe @mfuntowicz ran the slow tests on this one and there were no failures, but this PR is so cryptic I don't understand what's happening.

This issue has been automatically marked as stale and been closed because it has not had recent activity. Thank you for your contributions.

If you think this still needs to be addressed please comment on this thread.
Dont use sigmoid when num_labels==1
Author: abhishekkrthakur
Pull request: yes

It seems like we use MSELoss when num_labels==1 in config, i.e. a single column regression problem. But in text_classification pipeline, this is considered as a classification problem and uses sigmoid. This PR fixes that issue. 

Comments:
Sorry, I don't really understand this - could give a bit more context?

@patrickvonplaten Please see this https://github.com/huggingface/transformers/blob/master/src/transformers/models/bert/modeling_bert.py#L1515
or any `XForSequenceClassification` model

This is a very big breaking change. What do you think of the proposed approach here? https://github.com/huggingface/transformers/pull/8328
I think it allows what you're looking for, but in backwards-compatible way.

The PR is old and the diff isn't very readable, but if that's something that could fit your use case I can update it to the latest code.

@LysandreJik The way it's done in the pipeline here is absolutely incorrect. If the model is trained using MSELoss when num_labels = 1, it means that it is a regression problem and in that case, we should return raw values, not sigmoid. 
Returning raw values can be an option but for now, this fix is important as the values returned for num_labels=1 in this pipeline is incorrect: it should return raw value for regression, not sigmoid.

@LysandreJik Also, I didn't understand what would this PR break? 

Thank you for your feedback. It was done this way in order to enable inference on [DialogRPT](https://github.com/golsun/DialogRPT). It was the first model that performed sequence classification with a single label, so we defined it this way as you can see in this issue https://github.com/huggingface/transformers/issues/7493.

I understand that this is an issue for most cases, so being able to return raw values is important. However, we must find a way to do it in a backwards compatible way. We can't just change the code and break all models that rely on that pipeline.

> @LysandreJik Also, I didn't understand what would this PR break?

Well, for one, all of the DialogRPT models on the [hub](https://huggingface.co/models?search=dialogrpt).

I have updated PR #8328 for better readability. If this suits your use-case, I'll try to have it merged ASAP so as not to be blocking for you.

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/master/CONTRIBUTING.md) are likely to be ignored.
[run_glue] Add MNLI compatible mode
Author: JetRunner
Pull request: yes

In this PR:

- Upgrade `datasets` to `1.3.0`
- Rename `datasets` variable to `task_datasets` in `run_glue.py` to avoid confusion with the library `datasets`
- Add a `--mnli_compat_mode` option to use the old label assignment for MNLI

Comments:
The CI failed but it seems irrelevant. Could you please give it a check? @LysandreJik 

The CI issue is with `test_hf_api`, which is fixed on master now, rebasing should make the CI green!

@sgugger Sorry but I can't really agree with you here. It is a problem introduced by mistake and we shouldn't just try to ignore or downplay that. It just adds a few lines of if-else and I don't think it'll add too much burden for users. I can add some comments if it helps explain the code.

I am never a fan of trainer-style code since IMO in the context of ML, capsulation is not simplicity, instead, transparency is simplicity (I believe our user survey supports my claim here). Thus, I don't think our example here is meant for beginners at all. Besides, I do think back-compatibility matters especially when our success depends heavily on the prosperity of the model hub. This PR is meant to fix a bug though it's harsh. I want the users won't feel confused when they load a community model and wonder why it doesn't work. (Because I myself spent one whole day debugging this)


Happy to have more discussion here.

So we discussed it a bit more internally. This particular example script will stay as is with the backward-compatibility problem (which isn't one IMO since the problem is in the model config not having the right labels). As I said before it's an example aimed at data scientists that shouldn't necessarily have all the functionality.

There will be another script for GLUE (probably by the end of the month) very soon that doesn't use `Trainer` and has the training loop exposed, where we can integrate your fix.

Looking forward to the new script you mentioned!
attention_mask -> encoder_attention_mask in cross attn of BERT-like models
Author: abhishekkrthakur
Pull request: yes
Labels: name: wontfix


Comments:
This issue has been automatically marked as stale and been closed because it has not had recent activity. Thank you for your contributions.

If you think this still needs to be addressed please comment on this thread.

Reopened as this might still be in the works.

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/master/CONTRIBUTING.md) are likely to be ignored.

Unstale

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/master/CONTRIBUTING.md) are likely to be ignored.

@abhi1thakur - should we still try to merge this 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/master/CONTRIBUTING.md) are likely to be ignored.
BertForSemanticSimilarity
Author: abhishekkrthakur
Pull request: yes


Comments:
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/master/CONTRIBUTING.md) are likely to be ignored.
Fix loss reporting with deepspeed
Author: sgugger
Pull request: yes

# What does this PR do?

In the deepspeed integration inside `Trainer`, the loss currently reported is the scaled loss, as in scaled by the loss scaling factor used during mixed precision training. This has nothing to do with the actual loss (the scaling factor is the highest possible value that does not make the gradients overflow basically), this PR fixes that.

Fixes #11919

Comments:
This is exactly what deepspeed already does. Please see:

https://github.com/microsoft/DeepSpeed/blob/master/deepspeed/runtime/engine.py#L1142-L1143

The scaling function is:
```
    def _scale_loss_by_gas(self, prescaled_loss):
        if isinstance(prescaled_loss, torch.Tensor):
            scaled_loss = prescaled_loss / self.gradient_accumulation_steps()
        elif isinstance(prescaled_loss, tuple) or isinstance(prescaled_loss, list):
            scaled_loss = []
            for l in prescaled_loss:
                if isinstance(l, torch.Tensor):
                    scaled_loss.append(l / self.gradient_accumulation_steps())
                else:
                    scaled_loss.append(l)
        else:
            scaled_loss = prescaled_loss
            if self.warn_unscaled_loss:
                logger.warning(
                    f'DeepSpeed unable to scale loss because of type: {type(prescaled_loss)}'
                )
                self.warn_unscaled_loss = False

        return scaled_loss
```

it's scaled by gradient acc steps and not scaling factor.

I spent some more time running tests, including fp16, and I can't find any problem with the current code. 

As posted in a comment above reviewing the code shows that it only scales by grad acc steps.
Model output dict
Author: sgugger
Pull request: yes

# What does this PR do?

Currently, instantiating a `ModelOutput` from a dictionary does not yield proper results. It nests the dictionary in the first field instead of populating the fields with the content of the dictionary.

This PR fixes that and adds a regression test to make sure this behavior is not accidentally removed.

Comments:
Arg, branched from the wrong point. CLosing and reopening.
Validate onnx model
Author: mfuntowicz
Pull request: yes

Test ONNX model export with different input shapes when exporting with dynamic axis.

Comments:
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/master/CONTRIBUTING.md) are likely to be ignored.

Unstale

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/master/CONTRIBUTING.md) are likely to be ignored.
Skip ONNX LayoutLM test
Author: LysandreJik
Pull request: yes

Skips test until https://github.com/huggingface/transformers/pull/13562#issuecomment-925395462 is resolved

Comments:
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/master/CONTRIBUTING.md) are likely to be ignored.
Faster model templates
Author: LysandreJik
Pull request: yes

Changes the container for the model templates to speed up significantly the environment setup.

Comments:
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/master/CONTRIBUTING.md) are likely to be ignored.
Build dev doc
Author: LysandreJik
Pull request: yes


Comments:
This should be nearly good to go, only need to check that on close it doesn't actually regenerate the modifications of the PR.

Will take a stab at that tomorrow morning cc @sgugger @mishig25 

Will only need to change the target of the `git add` directive and it should be good to go

As said in private, this won't work for branches that have a different origin than `transformers`, since those won't get access to the secrets for security reasons.
Build dev doc
Author: LysandreJik
Pull request: yes


Comments:
Thank you for your PR. The documentation will now be removed from the staging environment - feel free to reopen this PR to recreate it.

Thank you for your PR. The documentation will now be removed from the staging environment - feel free to reopen this PR to recreate it.

Thank you for your PR! The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_15151). All of your documentation changes will be reflected on that endpoint.

Thank you for your PR. The documentation will now be removed from the staging environment - feel free to reopen this PR to recreate it.

Closing a PR puts the message above ^ merging a PR does too, without the invitation to reopen the PR

Thank you for your PR! The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_15110).\n\nAll of your documentation changes will be reflected on that endpoint.

I'll remove the `\n\n` but other than that, does the message look good to you?

Closing
Add parameter --config_overrides for run_mlm_wwm.py
Author: conan1024hao
Pull request: yes

## WHY
- I noticed that the parameter `--config_overrides`  is only available in `run_clm.py`, `run_plm.py` and `run_mlm.py` in `examples/pytorch/language-modeling`, but not available in `run_mlm_wwm.py` in `examples/research_projects/mlm_wwm/run_mlm_wwm.py`.
- However, I want to train a wwm model from scratch too, so we need this parameter.

## WHAT
- Added the parameter `--config_overrides` in `run_mlm_wwm.py`.

Comments:
_The documentation is not available anymore as the PR was closed or merged._

@sgugger @wlhgtc @LowinLi Please review this PR if you have time thank you.

Thanks for your PR. Note that we don't maintain research projects, they are pinned to work with a specific version of Transformers. You will need approval from the original author of the script to have this merged :-)

@sgugger Thank you for reply. However I can not find the earliest history of `run_mlm_wwm.py`... Is @wlhgtc the original author?

@conan1024hao  LGTM
And  @sgugger can you help merge this PR ?  

Sure thing!
Rename to reflect framework pattern AutoModelXxx -> TFAutoModelXxx
Author: amyeroberts
Pull request: yes

# What does this PR do?

Fixes a small bug to make sure a TFAutoModel class keeps the TF naming pattern when being updated with `auto_class_update`.

## Before submitting
- [ ] 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://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? 
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?

## Who can review?

Anyone in the community is free to review the PR once the tests have passed. 

Comments:
_The documentation is not available anymore as the PR was closed or merged._

Thank you for the fix, @amyeroberts 🚀 

@amyeroberts You can now merge the PR (`Squash and merge` button)
set eos_token_id to None to generate until max length
Author: ydshieh
Pull request: yes

# What does this PR do?

Update `check_encoder_decoder_model_generate` to generate until max length.
Otherwise, this check

```python
self.assertEqual(generated_output.shape, (input_ids.shape[0],) + (decoder_config.max_length,))
```

might fail.

### Remark

In `generate()`, we have

https://github.com/huggingface/transformers/blob/dced262409177586bb510b6b724c762fb89da0e8/src/transformers/generation_utils.py#L1129-L1133

So I think the (original) logic about `Generate until max length` in `check_encoder_decoder_model_generate` should be updated too. The case won't really happen in the tests, but in general, `config` might still have `eos_token_id`.

I also leave the corresponding flax tests untouched for now.

This PR will fix

```
FAILED tests/models/vision_encoder_decoder/test_modeling_vision_encoder_decoder.py::Swin2BartModelTest::test_encoder_decoder_model_generate

tests/vision_encoder_decoder/test_modeling_vision_encoder_decoder.py:280: in check_encoder_decoder_model_generate
self.assertEqual(generated_output.shape, (inputs.shape[0],) + (decoder_config.max_length,))
AssertionError: torch.Size([13, 2]) != (13, 20)
```


Comments:
_The documentation is not available anymore as the PR was closed or merged._
Update README to latest release
Author: sgugger
Pull request: yes

# What does this PR do?

The main README (and its variants) all have multiple links to released models that point to the main doc and not the stable doc. This is because we did the last two releases on branches different from the main one, so the README cleaned by our tools was not set on the main branch.

This PR fixes that and adds instructions in our release guide.

Comments:
_The documentation is not available anymore as the PR was closed or merged._