C-language code-block lexing error with specific comment syntax "//@"

[srikumarks]

I'd reported this originally here - sphinx-doc/sphinx#9548 - but it turns out that Sphinx is using pygments highlighter which independently shows the same behaviour I reported there. So copying the issue over.

Describe the bug

The following code block causes a C-language "lexing error" to be reported and highlighting skipped.

.. code-block :: c

    int div(int x, int y)
    //@requires y >= 0;
    {
        return x / y;
    }

On the other hand, if I just remove the trailing semicolon on the comment line, the error goes away. i.e. the below version lexes fine.

.. code-block :: c

    int div(int x, int y)
    //@requires y >= 0
    {
        return x / y;
    }

.. and the following lexes fine too -

.. code-block :: c

    int div(int x, int y)
    // requires y >= 0;
    {
         return x / y;
    }

Since the line in question is a comment line, what characters feature within the comment line should not be of any consequence for lexing the block as "C".

How to Reproduce

Include the example code blocks shown in any rst documentation processed by Sphinx. The following note by @jakobandersen shows how to reproduce it using pygmentize.

Thanks for reporting, though the lexing and highlighting is under the hood done with Pygments. It seems that running
pygmentize -l c -F raiseonerror test.c emulates what Sphinx does, and for your first example I indeed get an error:

*** Error while highlighting:
pygments.filters.ErrorToken: @
   (file "/home/jla/.local/lib/python3.8/site-packages/pygments/filters/__init__.py", line 782, in filter)
*** If this is a bug you want to report, please rerun with -v.
int div(int x, int y)

Expected behavior

All the indicated C-language code blocks should lex fine since the line in question is a comment line.

[lambda-karlculus]

Hi, I'm a student from the University of Adelaide. I'm working in a team of 5 on contributing to an OSS project. The duration of the project is 8 weeks. We would like to tackle this issue, if it is still available. Our current proposed timeline aims to have the issue fixed at the start of May. The lecturer for this course has already approved this issue as appropriate for our project.