Fix grammar for `RangePatternBound` regarding literals
The compiler, in parsing, accepts many more kinds of literals in the
bound of a range pattern than what we had documented, and as with
`PatternWithoutRange`, the parser allows each of these literals to be
prefixed with `-`. E.g.
```rust
#[cfg(any())]
match () {
..-true | ..-false => (),
..-'x' => (),
..-b'x' => (),
..-"x" => (),
..-r"x" => (),
..-br"x" => (),
..-c"x" => (),
..-cr"x" => (),
..-1 => (),
..-1.1 => (),
}
```
Let's fix this by adjusting the `RangePatternBound` production to use
`LiteralPattern`. In a separate PR, we've adjusted `LiteralPattern`
to allow for a minus sign ahead of all literal expressions.
To help the reader, let's also add a note that highlights that what we
discuss later as being allowed semantically is more restrictive than
what we allow in parsing (and therefore in the grammar).
diff --git a/src/patterns.md b/src/patterns.md
index 2d9ddb5..d28d58c 100644
--- a/src/patterns.md
+++ b/src/patterns.md
@@ -497,10 +497,7 @@
RangePatternBound `...` RangePatternBound
RangePatternBound ->
- CHAR_LITERAL
- | BYTE_LITERAL
- | `-`? INTEGER_LITERAL
- | `-`? FLOAT_LITERAL
+ LiteralPattern
| PathExpression
```
@@ -553,7 +550,11 @@
* A character, byte, integer, or float literal.
* A `-` followed by an integer or float literal.
-* A [path]
+* A [path].
+
+> [!NOTE]
+>
+> We syntactically accept more than this for a *[RangePatternBound]*. We later reject the other things semantically.
r[patterns.range.constraint-bound-path]
If a bound is written as a path, after macro resolution, the path must resolve to a constant item of the type `char`, an integer type, or a float type.
