The attribute @ocaml.warn_on_literal_pattern enables a warning for code that uses a literal pattern to match a constructor's arguments.

# exception E of string [@ocaml.warn_on_literal_pattern];;
exception E of string
# try () with E "foo" -> ();;
Characters 14-19:
  try () with E "foo" -> ();;
                ^^^^^
Warning 52: Code should not depend on the actual values of
this constructor's arguments. They are only for information
and may change in future versions. (See manual section 9.5)
- : unit = ()

Predefined exceptions, such as Failure, are marked with the attribute to dissuade people writing exception-handling code from relying on the value of the exception's arguments:

# try () with Failure "foo" -> ();;
Line 1, characters 20-25:
1 | try () with Failure "foo" -> ();;
                        ^^^^^
Warning 52: Code should not depend on the actual values of
this constructor's arguments. They are only for information
and may change in future versions. (See manual section 9.5)
- : unit = ()

However, the warning is currently arbitrarily restricted to constructors of a single non-tuple argument, and so no warning is emitted for more complex patterns:

# try "" with Failure ("foo" as s) -> s;;
- : string = ""
# try () with Match_failure ("foo", _, _) -> ();;
- : unit = ()
# try () with Failure ("foo" : string ) -> ();;
- : unit = ()

This PR extends the definition of 'literal pattern' so that warnings are emitted in these cases, too.

#254 has some previous discussion of the attribute/warning, and the possibility of extending them beyond a single constructor. @gasche's comment is particularly relevant:

#Following #379, I have regrets about the current state of the this PR. Due to implementation limitations, we only support constructors with a single argument, but using the attribute on constructors with several arguments will just silently make it meaningless and not warn the user in any way. This is very bad usability.