Missing syntax highlighting for LLVM IR in Langref

[sushmaunnibhavi]

Summary

Added syntax highlighting

[fhahn]

Thanks for the patch! But do we do that for the other instruction syntax blocks as well? AFAICT the syntax blocks are not valid IR (due to the <> blocks) and .. code-block:: llvm is only used for examples with valid IR?

[xgupta]

I think Comdats, Prologue Data, Preallocated Operand Bundles, Use-list Order Directives, Undefined Values, Metadata Nodes and Metadata Strings, DICompileUnit, DIFile, DIBaiscType, DI ... etc, callback, associated metadata, annotation, C type width Module Flags Metadata, Automatic Linker Flags Named Metadata, Params, callbr, callswitch, bitcast, etc ... have example section that needs LLVM syntax highlighting.
But please check that they are valid LLVM IR examples or not. Like variable name (called virtual register) that we can assign value start from % not <

You may take the help from the tutorial on LLVM IR recorded during the 2019 EuroLLVM Developers’ Meeting.

[xgupta]

Also please change the title to Missing syntax highlighting for LLVM IR in Langref as mention in the bug report with [Docs] tag.

[sushmaunnibhavi]

In D100125#2678582, @xgupta wrote:

I think Comdats, Prologue Data, Preallocated Operand Bundles, Use-list Order Directives, Undefined Values, Metadata Nodes and Metadata Strings, DICompileUnit, DIFile, DIBaiscType, DI ... etc, callback, associated metadata, annotation, C type width Module Flags Metadata, Automatic Linker Flags Named Metadata, Params, callbr, callswitch, bitcast, etc ... have example section that needs LLVM syntax highlighting.
But please check that they are valid LLVM IR examples or not. Like variable name (called virtual register) that we can assign value start from % not <

You may take the help from the tutorial on LLVM IR recorded during the 2019 EuroLLVM Developers’ Meeting.

Yes, I will look into it.

[sushmaunnibhavi]

Added missing syntax highlighting

[xgupta]

LGTM

llvm/docs/LangRef.rst

.. code-block:: text
 
    define void @bar() comdat($foo) {
      ret void
    }
 
 As a syntactic sugar the ``$name`` can be omitted if the name is the same as
 the global name:
 
-.. code-block:: text
+.. code-block:: llvm
 
   $foo = comdat any
   @foo = global i32 2, comdat
 
 
 In a COFF object file, this will create a COMDAT section with selection kind
 ``IMAGE_COMDAT_SELECT_LARGEST`` containing the contents of the ``@foo`` symbol
 and another COMDAT section with selection kind
 ``IMAGE_COMDAT_SELECT_ASSOCIATIVE`` which is associated with the first COMDAT
 section and contains the contents of the ``@bar`` symbol.
 
 There are some restrictions on the properties of the global object.
 It, or an alias to it, must have the same name as the COMDAT group when
 targeting COFF.
 The contents and size of this object may be used during link-time to determine
 which COMDAT groups get selected depending on the selection kind.
 Because the name of the object must match the name of the COMDAT group, the
 linkage of the global object must not be local; local symbols can get renamed
 if a collision occurs in the symbol table.
 
 The combined use of COMDATS and section attributes may yield surprising results.
 For example:
 
-.. code-block:: text
+.. code-block:: llvm
 
    $foo = comdat any
    $bar = comdat any
    @g1 = global i32 42, section "sec", comdat($foo)
    @g2 = global i32 42, section "sec", comdat($bar)
 
 From the object file perspective, this requires the creation of two sections
 with the same name. This is necessary because both globals belong to different