a shift-reduce conflict

Imagine the conveyor-belt worker reaching a moment where two actions both look valid: they could clip the parts already on the table into a finished piece, or wait and grab the next item off the belt first, and the instructions do not say which. Frozen between the two, they cannot proceed. A shift-reduce conflict is exactly this dilemma inside an LR parser: in some state, with some look-ahead token, the table says both 'shift' and 'reduce' are possible, and there is no way to choose.

Conflicts come in two flavours. A shift-reduce conflict means the parser cannot tell whether to push the next token or to reduce what is on the stack; the classic case is the dangling-else, where after if E then S the parser sees else and cannot tell whether else attaches to this if or an outer one. A reduce-reduce conflict means two different rules could both apply to reduce the same handle, and the parser cannot tell which. Conflicts arise when the grammar is ambiguous, or when it is unambiguous but simply not within the chosen LR variant's power. The standard cures are: declare operator precedence and associativity (telling the tool that, say, * binds tighter than + and + groups left, which silently resolves arithmetic shift-reduce conflicts the right way), rewrite the grammar to eliminate the ambiguity, or for dangling-else adopt the common convention 'else matches the nearest unmatched if', which is exactly resolving the conflict in favour of shift.

Conflicts matter because they are the everyday way grammar problems show up when you run a parser generator: bison prints 'N shift/reduce conflicts' and quietly resolves them by a default rule (shift wins) that may or may not be what you meant. Treating conflicts as warnings to investigate, not noise to ignore, is the difference between a grammar that parses what you intended and one that silently misreads programs.