Adding DocTest to TrOCR
Author: arnaudstiegler
Pull request: yes

# Adding TrOCR to DocTests

For this model, there was actually a single docstring in the entire file (for the forward method).

A couple of comments:
- As far as I'm aware, there is no TF version of this model
- TrOCR is an edge case because it's meant to be used as the decoder for a VisionEncoderDecoder. So the forward function of the TrOCR is not meant to be called directly. As a result, I gave some example code to run a forward pass with TrOCR within a VisionEncoderDecoder 

Let me know if the docstring is relevant to the problem. I can also revert adapt it to actually just showcase the forward for the `TrOCRForCausalLM` outside of a VisionEncoderDecoder

@patrickvonplaten @ydshieh @patil-suraj 

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

I took a quick look for now, and think it is indeed a nice addition, considering there is currently no example in `modeling_trocr.py` at all.
Thank you, @arnaudstiegler!



Addressed the comments and re-ran the test locally!
There's one thing though: `make fixup` messes up the formatting of the docstring, and removes the additional blank at the end of the docstring ([here](https://github.com/huggingface/transformers/blob/ae63ca7033aa1d6220a855498a5403d846ba51b3/src/transformers/models/trocr/modeling_trocr.py#L933-L934)). The issue is that without the additional line, doctest will fail when comparing outputs. Not sure why to be honest, but do you know how to prevent that `make fixup` from doing this? Otherwise, next time the file is touched, make fixup will introduce a bug in the docstring.

Here's the failure:
```
Expected:
    ['industry, " Mr. Brown commented icily. " Let us have a']
    ```
Got:
    ['industry, " Mr. Brown commented icily. " Let us have a']

```

Essentially, without the additional line, the test consider that ``` is part of the expected output. But that additional line gets removed by make fixup. I haven't found a good way around this yet


@ydshieh 

Those blank lines issues should be treated by the places regarding `utils/prepare_for_doc_test.py` as shown in this guide [doc](https://github.com/huggingface/transformers/tree/main/docs#for-python-files).

This means you don't need to add extra blank line in the file. Did you run `python utils/prepare_for_doc_test.py` as in the guide before and after running the doctest?

Got it! I did run the script and it seems like it's not being applied to the trocr (but I can see the added lines on other model files). I'll debug that today

OK, thank you. Don't hesitate to report it if you find this is some bug in `prepare_for_doc_test.py`.

> OK, thank you. Don't hesitate to report it if you find this is some bug in `prepare_for_doc_test.py`.

Figured out the issue: there was some formatting issue in one of the docstring (see last commit) that prevented the script to correctly add a line. From `utils.prepare_for_doc_test.process_doc_file`
```
splits = code.split("```")
splits = [s if i % 2 == 0 else process_code_block(s, add_new_line=add_new_line) for i, s in enumerate(splits)]
```
splits were incorrect because of that, and the script wouldn't add an additional \n
Now the doctest runs fine post `make fixup`
Should be good to go

@ydshieh Is there anything else to do? I don't have writing access here, so I can't merge this

Rebased on latest main and addressed the comments, the failing test is coming from main (failing on main as well)

Hi, the failed check seems irrelevant to your PR. No need to fix it here 😃. I will give a final look and merge. Thank you 💗

Alright, thank you!

By the way, may I wonder why you choose to display 3 decimal numbers for the loss value? I remember we use 2 decimal numbers in doc.py. I will check once I am available.

Applied your changes, tested them locally, and ran make fixup as this was needed after the changes

If the remaining failed checks are  **build_pr_documentation** and **Add new model like template tests**, you can keep the PR as it is. It is irrelevant I think.

Ok, I tried rebasing on latest master and it doesn't seem to be doing the trick. Not sure what's causing that unfortunately, but unlikely to be due to the code changes I've done :)


Thank you again @arnaudstiegler ! (also for your patience)

I merge this PR now ❤️.