`transformers.models.bart.modeling_bart._prepare_bart_decoder_inputs` seems to be renamed but remains in the document
Author: forest1988
Pull request: no

## Environment info
     
- `transformers` version: 4.1.1
- Platform: Linux-4.15.0-123-generic-x86_64-with-glibc2.10
- Python version: 3.8.3
- PyTorch version (GPU?): 1.7.0 (True)
- Tensorflow version (GPU?): 2.3.1 (True)
- Using GPU in script?: Yes
- Using distributed or parallel set-up in script?: No

### Who can help
 Bart: @patrickvonplaten

## Information

Model I am using (Bert, XLNet ...): Bart

The problem arises in the [model_doc/bart.rst](https://github.com/huggingface/transformers/blob/v4.1.1/docs/source/model_doc/bart.rst#implementation-notes)

## To reproduce

In our code using transformers v3.4.0, we have used :
```
from transformers.modeling_bart import _prepare_bart_decoder_inputs
```
I tried to rerewrite it as:
```
try:  # transformers >= v4
    from transformers.models.bart.modeling_bart import _prepare_bart_decoder_inputs
except ModuleNotFoundError:  # transformers == v3.4.0
    from transformers.modeling_bart import _prepare_bart_decoder_inputs
```
but It seems Bart (modeling_bart) in v4.1.1 doesn't have `_prepare_bart_decoder_inputs` in its implementation.
However, [model_doc/bart.rst](https://github.com/huggingface/transformers/blob/v4.1.1/docs/source/model_doc/bart.rst#implementation-notes) says 

> The forward pass of :class:`~transformers.BartModel` will create decoder inputs (using the helper function :func:`transformers.models.bart.modeling_bart._prepare_bart_decoder_inputs`) if they are not passed. This is different than some other modeling APIs.


I think maybe the function is renamed in the refactoring of Bart #8900.
I welcome this refactoring as I would love to take advantage of Bart (and other Seq2SeqLMs), but I am wondering how I can fix the old code to get the best performance out of the refactored code.
Do you have any document about how to fix the old code to work well with the new version of the Bart?

## Expected behavior

Maybe model_doc/bart.rst needs to be updated.
I'm sorry if there is already an appropriate documentation.

Comments:
Hey @forest1988,

Thanks a lot for your issue - you're 100% correct, the docs need to be updated here - I'll open a PR for this and tag you.
So to give some context on why this function doesn't exist anymore.

- We are trying to align the API of all models which makes it easier for users to switch from one model to the other. No other model had such a function.
- The function was only called internally, so you don't really to care about the change as long as you only call the public API of Bart being at the moment the `forward pass` of `BartModel` and `BartForConditionalGeneration`. All possible behaviors of pubic API functions should have stayed 1-to-1 the same for Bart.
- In the bullet point in question, it says that the model will create the `decoder_input_ids` if they are not passed. This is a very Bart-specific feature and is only really be used in two cases:
 1) You want to do <mask-filling> for bart as shown in the example in this section: https://huggingface.co/transformers/model_doc/bart.html#transformers.BartForConditionalGeneration . In this case you only have to pass the `input_ids` and Bart will correctly output something. All non-Bart seq2seq model yield an error here because they expect the `decoder_input_ids` to be passed as well (which should be the default case IMO). Bart is able to do this task thanks to its rather specific pre-training objective.
2) (This is the same for all Seq2Seq models) you pass `labels` and `input_ids` => this is used fro training and in this case Bart (and all other seq2seq models except EncoderDecoderModel) shift the labels to the right to create the `decoder_input_ids`.

So in short, the function doesn't exist anymore in the new code. If you adapted "old" bart code to your specific needs and are now stuck to "port" it to the new Bart code, I'd suggest to write an integration test using your "old" bart code and then closely look at what was done in #8900 to adapt your code analogously. If you're completely stuck,  feel free to post an issue here and tag me - I'll help you then :-) 

@patrickvonplaten 
Thank you for your quick comments and for solving the issue! I've checked PR #9299 and would like to say thank you for tagging me there.

Some time ago, we tried to use various Seq2SeqLMs but had trouble using them in a unified way. The update of aligning APIs is very helpful!

I read carefully your comments and linked documents, will write an integration test, and closely look #8900 to adapt my code analogously. 
If I’ll be still completely stuck, I would like to take your word and ask for your help.

Thank you again!