Skip to content

Commit fbd8cc1

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 58a96b8 + 2b92f9f commit fbd8cc1

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
@@ -62,13 +62,62 @@ mod mut_visit {
6262
}
6363

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

0 commit comments

Comments
 (0)