Skip to content

Commit a477172

Browse files
authored
Rollup merge of #140494 - ehuss:document-restrictions, r=traviscross,SparrowLii
Parser: Document restrictions I had trouble easily understanding what these various flags do. This is my attempt to try to explain what these do.
2 parents 5cb54f9 + 2b92f9f commit a477172

File tree

1 file changed

+49
-0
lines changed
  • compiler/rustc_parse/src/parser

1 file changed

+49
-0
lines changed

compiler/rustc_parse/src/parser/mod.rs

+49
Original file line numberDiff line numberDiff line change
@@ -58,13 +58,62 @@ mod tokenstream {
5858
}
5959

6060
bitflags::bitflags! {
61+
/// Restrictions applied while parsing.
62+
///
63+
/// The parser maintains a bitset of restrictions it will honor while
64+
/// parsing. This is essentially used as a way of tracking state of what
65+
/// is being parsed and to change behavior based on that.
6166
#[derive(Clone, Copy, Debug)]
6267
struct Restrictions: u8 {
68+
/// Restricts expressions for use in statement position.
69+
///
70+
/// When expressions are used in various places, like statements or
71+
/// match arms, this is used to stop parsing once certain tokens are
72+
/// reached.
73+
///
74+
/// For example, `if true {} & 1` with `STMT_EXPR` in effect is parsed
75+
/// as two separate expression statements (`if` and a reference to 1).
76+
/// Otherwise it is parsed as a bitwise AND where `if` is on the left
77+
/// and 1 is on the right.
6378
const STMT_EXPR = 1 << 0;
79+
/// Do not allow struct literals.
80+
///
81+
/// There are several places in the grammar where we don't want to
82+
/// allow struct literals because they can require lookahead, or
83+
/// otherwise could be ambiguous or cause confusion. For example,
84+
/// `if Foo {} {}` isn't clear if it is `Foo{}` struct literal, or
85+
/// just `Foo` is the condition, followed by a consequent block,
86+
/// followed by an empty block.
87+
///
88+
/// See [RFC 92](https://rust-lang.github.io/rfcs/0092-struct-grammar.html).
6489
const NO_STRUCT_LITERAL = 1 << 1;
90+
/// Used to provide better error messages for const generic arguments.
91+
///
92+
/// An un-braced const generic argument is limited to a very small
93+
/// subset of expressions. This is used to detect the situation where
94+
/// an expression outside of that subset is used, and to suggest to
95+
/// wrap the expression in braces.
6596
const CONST_EXPR = 1 << 2;
97+
/// Allows `let` expressions.
98+
///
99+
/// `let pattern = scrutinee` is parsed as an expression, but it is
100+
/// only allowed in let chains (`if` and `while` conditions).
101+
/// Otherwise it is not an expression (note that `let` in statement
102+
/// positions is treated as a `StmtKind::Let` statement, which has a
103+
/// slightly different grammar).
66104
const ALLOW_LET = 1 << 3;
105+
/// Used to detect a missing `=>` in a match guard.
106+
///
107+
/// This is used for error handling in a match guard to give a better
108+
/// error message if the `=>` is missing. It is set when parsing the
109+
/// guard expression.
67110
const IN_IF_GUARD = 1 << 4;
111+
/// Used to detect the incorrect use of expressions in patterns.
112+
///
113+
/// This is used for error handling while parsing a pattern. During
114+
/// error recovery, this will be set to try to parse the pattern as an
115+
/// expression, but halts parsing the expression when reaching certain
116+
/// tokens like `=`.
68117
const IS_PAT = 1 << 5;
69118
}
70119
}

0 commit comments

Comments
 (0)