]> git.saurik.com Git - bison.git/blame_incremental - src/state.h
#
[bison.git] / src / state.h
... / ...
CommitLineData
1/* Type definitions for nondeterministic finite state machine for bison,
2 Copyright (C) 1984, 1989 Free Software Foundation, Inc.
3
4This file is part of Bison, the GNU Compiler Compiler.
5
6Bison is free software; you can redistribute it and/or modify
7it under the terms of the GNU General Public License as published by
8the Free Software Foundation; either version 2, or (at your option)
9any later version.
10
11Bison is distributed in the hope that it will be useful,
12but WITHOUT ANY WARRANTY; without even the implied warranty of
13MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
14GNU General Public License for more details.
15
16You should have received a copy of the GNU General Public License
17along with Bison; see the file COPYING. If not, write to
18the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */
19
20
21/* These type definitions are used to represent a nondeterministic
22 finite state machine that parses the specified grammar.
23 This information is generated by the function generate_states
24 in the file LR0.
25
26Each state of the machine is described by a set of items --
27particular positions in particular rules -- that are the possible
28places where parsing could continue when the machine is in this state.
29These symbols at these items are the allowable inputs that can follow now.
30
31A core represents one state. States are numbered in the number field.
32When generate_states is finished, the starting state is state 0
33and nstates is the number of states. (A transition to a state
34whose state number is nstates indicates termination.) All the cores
35are chained together and first_state points to the first one (state 0).
36
37For each state there is a particular symbol which must have been the
38last thing accepted to reach that state. It is the accessing_symbol
39of the core.
40
41Each core contains a vector of nitems items which are the indices
42in the ritems vector of the items that are selected in this state.
43
44The link field is used for chaining buckets that hash states by
45their itemsets. This is for recognizing equivalent states and
46combining them when the states are generated.
47
48The two types of transitions are shifts (push the lookahead token
49and read another) and reductions (combine the last n things on the
50stack via a rule, replace them with the symbol that the rule derives,
51and leave the lookahead token alone). When the states are generated,
52these transitions are represented in two other lists.
53
54Each shifts structure describes the possible shift transitions out
55of one state, the state whose number is in the number field.
56The shifts structures are linked through next and first_shift points to them.
57Each contains a vector of numbers of the states that shift transitions
58can go to. The accessing_symbol fields of those states' cores say what kind
59of input leads to them.
60
61A shift to state zero should be ignored. Conflict resolution
62deletes shifts by changing them to zero.
63
64Each reductions structure describes the possible reductions at the state
65whose number is in the number field. The data is a list of nreds rules,
66represented by their rule numbers. first_reduction points to the list
67of these structures.
68
69Conflict resolution can decide that certain tokens in certain
70states should explicitly be errors (for implementing %nonassoc).
71For each state, the tokens that are errors for this reason
72are recorded in an errs structure, which has the state number
73in its number field. The rest of the errs structure is full
74of token numbers.
75
76There is at least one shift transition present in state zero.
77It leads to a next-to-final state whose accessing_symbol is
78the grammar's start symbol. The next-to-final state has one shift
79to the final state, whose accessing_symbol is zero (end of input).
80The final state has one shift, which goes to the termination state
81(whose number is nstates-1).
82The reason for the extra state at the end is to placate the parser's
83strategy of making all decisions one token ahead of its actions. */
84
85
86typedef
87 struct core
88 {
89 struct core *next;
90 struct core *link;
91 short number;
92 short accessing_symbol;
93 short nitems;
94 short items[1];
95 }
96 core;
97
98
99
100typedef
101 struct shifts
102 {
103 struct shifts *next;
104 short number;
105 short nshifts;
106 short shifts[1];
107 }
108 shifts;
109
110
111
112typedef
113 struct errs
114 {
115 short nerrs;
116 short errs[1];
117 }
118 errs;
119
120
121
122typedef
123 struct reductions
124 {
125 struct reductions *next;
126 short number;
127 short nreds;
128 short rules[1];
129 }
130 reductions;
131
132
133
134extern int nstates;
135extern core *first_state;
136extern shifts *first_shift;
137extern reductions *first_reduction;