Dont count throw as an exit node (React semantics)

React will retry or abort components that throw (depending on a few conditions), so from React's perspective a `throw` statement is not a normal exit node. Thus the Rules of Hooks really have a caveat: the set of hooks that are called _in an execution that returns successfully_ must be consistent. Examples such as the following are therefore allowed: ```javascript function Component(props) { if (props.cond) { throw new Error(...); } useHook(); } ``` By modeling `throw` as an exit node, we rejected cases such as this. This diff changes to not model throws as exit nodes. #1584 changes this to make it an option, since some cases will want to consider throw as an exit node.

Joe Savona committed May 8, 2023 at 13:58 UTC 8920fc0b2f82f8922c082c271503e3c156ed85cc

1 file changed +4 -5

compiler/forget/src/HIR/Dominator.ts

+4 -5

@@ -113,10 +113,9 @@ class Dominator<T> {

113 */

114 get(id: T): T | null {

115 const dominator = this.#nodes.get(id);

116 - invariant(

117 - dominator !== undefined,

118 - `Called on invalid node identifier '${id}'`

119 - );

116 + if (dominator === undefined) {

117 + return null;

118 + }

119 return dominator === id ? null : dominator;

120 }

121

@@ -173,7 +172,7 @@ function computeReverseGraph(fn: HIRFunction): Graph<BlockId> {

172 preds: new Set(eachTerminalSuccessor(block.terminal)),

173 succs: new Set(block.preds),

174 };

176 - if (block.terminal.kind === "return" || block.terminal.kind === "throw") {

175 + if (block.terminal.kind === "return") {

176 node.preds.add(exitId);

177 exit.succs.add(id);

178 }