{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":10270250,"defaultBranch":"main","name":"react","ownerLogin":"facebook","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2013-05-24T16:15:54.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/69631?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1716503864.0","currentOid":""},"activityList":{"items":[{"before":"e2d5a184694c139d335c728b4587cdb47f0a426b","after":null,"ref":"refs/heads/float-precedence-ordering","pushedAt":"2024-05-23T22:37:44.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"eps1lon","name":"Sebastian Silbermann","path":"/eps1lon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/12292047?s=80&v=4"}},{"before":"5be2fe2d74ba4326857f8e56b0ccf063a6466139","after":"fc578ff4b042dcf123e3bd419d300492764fed15","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-23T21:25:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Fix async batching in React.startTransition (#29226)\n\nNote: Despite the similar-sounding description, this fix is unrelated to\nthe issue where updates that occur after an `await` in an async action\nmust also be wrapped in their own `startTransition`, due to the absence\nof an AsyncContext mechanism in browsers today.\n\n---\n\nDiscovered a flaw in the current implementation of the isomorphic\nstartTransition implementation (React.startTransition), related to async\nactions. It only creates an async scope if something calls setState\nwithin the synchronous part of the action (i.e. before the first\n`await`). I had thought this was fine because if there's no update\nduring this part, then there's nothing that needs to be entangled. I\ndidn't think this through, though — if there are multiple async updates\ninterleaved throughout the rest of the action, we need the async scope\nto have already been created so that _those_ are batched together.\n\nAn even easier way to observe this is to schedule an optimistic update\nafter an `await` — the optimistic update should not be reverted until\nthe async action is complete.\n\nTo implement, during the reconciler's module initialization, we compose\nits startTransition implementation with any previous reconciler's\nstartTransition that was already initialized. Then, the isomorphic\nstartTransition is the composition of every\nreconciler's startTransition.\n\n```js\nfunction startTransition(fn) {\n return startTransitionDOM(() => {\n return startTransitionART(() => {\n return startTransitionThreeFiber(() => {\n // and so on...\n return fn();\n });\n });\n });\n}\n```\n\nThis is basically how flushSync is implemented, too.\n\nDiffTrain build for commit https://github.com/facebook/react/commit/ee5c19493086fdeb32057e16d1e3414370242307.","shortMessageHtmlLink":"Fix async batching in React.startTransition (#29226)"}},{"before":"fe342b1c85ea1fff804cbf5afbe08cd464399789","after":"4374cb693d1572509aab1800d2a433b379625212","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-05-23T21:24:59.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Fix async batching in React.startTransition (#29226)\n\nNote: Despite the similar-sounding description, this fix is unrelated to\nthe issue where updates that occur after an `await` in an async action\nmust also be wrapped in their own `startTransition`, due to the absence\nof an AsyncContext mechanism in browsers today.\n\n---\n\nDiscovered a flaw in the current implementation of the isomorphic\nstartTransition implementation (React.startTransition), related to async\nactions. It only creates an async scope if something calls setState\nwithin the synchronous part of the action (i.e. before the first\n`await`). I had thought this was fine because if there's no update\nduring this part, then there's nothing that needs to be entangled. I\ndidn't think this through, though — if there are multiple async updates\ninterleaved throughout the rest of the action, we need the async scope\nto have already been created so that _those_ are batched together.\n\nAn even easier way to observe this is to schedule an optimistic update\nafter an `await` — the optimistic update should not be reverted until\nthe async action is complete.\n\nTo implement, during the reconciler's module initialization, we compose\nits startTransition implementation with any previous reconciler's\nstartTransition that was already initialized. Then, the isomorphic\nstartTransition is the composition of every\nreconciler's startTransition.\n\n```js\nfunction startTransition(fn) {\n return startTransitionDOM(() => {\n return startTransitionART(() => {\n return startTransitionThreeFiber(() => {\n // and so on...\n return fn();\n });\n });\n });\n}\n```\n\nThis is basically how flushSync is implemented, too.\n\nDiffTrain build for [ee5c19493086fdeb32057e16d1e3414370242307](https://github.com/facebook/react/commit/ee5c19493086fdeb32057e16d1e3414370242307)","shortMessageHtmlLink":"Fix async batching in React.startTransition (#29226)"}},{"before":"f55d172bcf921d761733533395b798c5b3665e04","after":"ee5c19493086fdeb32057e16d1e3414370242307","ref":"refs/heads/main","pushedAt":"2024-05-23T21:19:09.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Fix async batching in React.startTransition (#29226)\n\nNote: Despite the similar-sounding description, this fix is unrelated to\r\nthe issue where updates that occur after an `await` in an async action\r\nmust also be wrapped in their own `startTransition`, due to the absence\r\nof an AsyncContext mechanism in browsers today.\r\n\r\n---\r\n\r\nDiscovered a flaw in the current implementation of the isomorphic\r\nstartTransition implementation (React.startTransition), related to async\r\nactions. It only creates an async scope if something calls setState\r\nwithin the synchronous part of the action (i.e. before the first\r\n`await`). I had thought this was fine because if there's no update\r\nduring this part, then there's nothing that needs to be entangled. I\r\ndidn't think this through, though — if there are multiple async updates\r\ninterleaved throughout the rest of the action, we need the async scope\r\nto have already been created so that _those_ are batched together.\r\n\r\nAn even easier way to observe this is to schedule an optimistic update\r\nafter an `await` — the optimistic update should not be reverted until\r\nthe async action is complete.\r\n\r\nTo implement, during the reconciler's module initialization, we compose\r\nits startTransition implementation with any previous reconciler's\r\nstartTransition that was already initialized. Then, the isomorphic\r\nstartTransition is the composition of every\r\nreconciler's startTransition.\r\n\r\n```js\r\nfunction startTransition(fn) {\r\n return startTransitionDOM(() => {\r\n return startTransitionART(() => {\r\n return startTransitionThreeFiber(() => {\r\n // and so on...\r\n return fn();\r\n });\r\n });\r\n });\r\n}\r\n```\r\n\r\nThis is basically how flushSync is implemented, too.","shortMessageHtmlLink":"Fix async batching in React.startTransition (#29226)"}},{"before":"e574453c809d5e11a2058c7ece8a09532e691f91","after":"fe342b1c85ea1fff804cbf5afbe08cd464399789","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-05-23T20:59:52.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"[Fiber] clarify entry condition for suspensey commit recursion (#29222)\n\nPreviously Suspensey recursion would only trigger if the\nShouldSuspendCommit flag was true. However there is a dependence on the\nVisibility flag embedded in this logic because these flags share a bit.\nTo make it clear that the semantics of Suspensey resources require\nconsidering both flags I've added it to the condition even though this\nextra or-ing is a noop when the bit is shared\n\nDiffTrain build for [f55d172bcf921d761733533395b798c5b3665e04](https://github.com/facebook/react/commit/f55d172bcf921d761733533395b798c5b3665e04)","shortMessageHtmlLink":"[Fiber] clarify entry condition for suspensey commit recursion (#29222)"}},{"before":"a8171274423e1961f0f89d1285d6531df2d64525","after":"5be2fe2d74ba4326857f8e56b0ccf063a6466139","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-23T20:59:36.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"[Fiber] clarify entry condition for suspensey commit recursion (#29222)\n\nPreviously Suspensey recursion would only trigger if the\nShouldSuspendCommit flag was true. However there is a dependence on the\nVisibility flag embedded in this logic because these flags share a bit.\nTo make it clear that the semantics of Suspensey resources require\nconsidering both flags I've added it to the condition even though this\nextra or-ing is a noop when the bit is shared\n\nDiffTrain build for commit https://github.com/facebook/react/commit/f55d172bcf921d761733533395b798c5b3665e04.","shortMessageHtmlLink":"[Fiber] clarify entry condition for suspensey commit recursion (#29222)"}},{"before":"84239da896fd7395a667ab1e7ef1ef338a32de8f","after":"f55d172bcf921d761733533395b798c5b3665e04","ref":"refs/heads/main","pushedAt":"2024-05-23T20:54:52.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"gnoff","name":"Josh Story","path":"/gnoff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2716369?s=80&v=4"},"commit":{"message":"[Fiber] clarify entry condition for suspensey commit recursion (#29222)\n\nPreviously Suspensey recursion would only trigger if the\r\nShouldSuspendCommit flag was true. However there is a dependence on the\r\nVisibility flag embedded in this logic because these flags share a bit.\r\nTo make it clear that the semantics of Suspensey resources require\r\nconsidering both flags I've added it to the condition even though this\r\nextra or-ing is a noop when the bit is shared","shortMessageHtmlLink":"[Fiber] clarify entry condition for suspensey commit recursion (#29222)"}},{"before":null,"after":"e2d5a184694c139d335c728b4587cdb47f0a426b","ref":"refs/heads/float-precedence-ordering","pushedAt":"2024-05-23T17:48:06.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"eps1lon","name":"Sebastian Silbermann","path":"/eps1lon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/12292047?s=80&v=4"},"commit":{"message":"Current behavior of precedence ordering","shortMessageHtmlLink":"Current behavior of precedence ordering"}},{"before":"2de2c20e92164b55aa4e17dfee33489eeff7ad88","after":"e574453c809d5e11a2058c7ece8a09532e691f91","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-05-23T16:54:12.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Move createElement/JSX Warnings into the Renderer (#29088)\n\nThis is necessary to simplify the component stack handling to make way\nfor owner stacks. It also solves some hacks that we used to have but\ndon't quite make sense. It also solves the problem where things like key\nwarnings get silenced in RSC because they get deduped. It also surfaces\nareas where we were missing key warnings to begin with.\n\nAlmost every type of warning is issued from the renderer. React Elements\nare really not anything special themselves. They're just lazily invoked\nfunctions and its really the renderer that determines there semantics.\n\nWe have three types of warnings that previously fired in\nJSX/createElement:\n\n- Fragment props validation.\n- Type validation.\n- Key warning.\n\nIt's nice to be able to do some validation in the JSX/createElement\nbecause it has a more specific stack frame at the callsite. However,\nthat's the case for every type of component and validation. That's the\nwhole point of enableOwnerStacks. It's also not sufficient to do it in\nJSX/createElement so we also have validation in the renderers too. So\nthis validation is really just an eager validation but also happens\nagain later.\n\nThe problem with these is that we don't really know what types are valid\nuntil we get to the renderer. Additionally, by placing it in the\nisomorphic code it becomes harder to do deduping of warnings in a way\nthat makes sense for that renderer. It also means we can't reuse logic\nfor managing stacks etc.\n\nFragment props validation really should just be part of the renderer\nlike any other component type. This also matters once we add Fragment\nrefs and other fragment features. So I moved this into Fiber. However,\nsince some Fragments don't have Fibers, I do the validation in\nChildFiber instead of beginWork where it would normally happen.\n\nFor `type` validation we already do validation when rendering. By\nleaving it to the renderer we don't have to hard code an extra list.\nThis list also varies by context. E.g. class components aren't allowed\nin RSC but client references are but we don't have an isomorphic way to\nidentify client references because they're defined by the host config so\nthe current logic is flawed anyway. I kept the early validation for now\nwithout the `enableOwnerStacks` since it does provide a nicer stack\nframe but with that flag on it'll be handled with nice stacks anyway. I\nnormalized some of the errors to ensure tests pass.\n\nFor `key` validation it's the same principle. The mechanism for the\nheuristic is still the same - if it passes statically through a parent\nJSX/createElement call then it's considered validated. We already did\nprint the error later from the renderer so this also disables the early\nlog in the `enableOwnerStacks` flag.\n\nI also added logging to Fizz so that key warnings can print in SSR logs.\n\nFlight is a bit more complex. For elements that end up on the client we\njust pass the `validated` flag along to the client and let the client\nrenderer print the error once rendered. For server components we log the\nerror from Flight with the server component as the owner on the stack\nwhich will allow us to print the right stack for context. The factoring\nof this is a little tricky because we only want to warn if it's in an\narray parent but we want to log the error later to get the right debug\ninfo.\n\nFiber/Fizz has a similar factoring problem that causes us to create a\nfake Fiber for the owner which means the logs won't be associated with\nthe right place in DevTools.\n\nDiffTrain build for [84239da896fd7395a667ab1e7ef1ef338a32de8f](https://github.com/facebook/react/commit/84239da896fd7395a667ab1e7ef1ef338a32de8f)","shortMessageHtmlLink":"Move createElement/JSX Warnings into the Renderer (#29088)"}},{"before":"bde36f5c6131ef0421587170e2ef1058d27d3971","after":"a8171274423e1961f0f89d1285d6531df2d64525","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-23T16:54:07.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Move createElement/JSX Warnings into the Renderer (#29088)\n\nThis is necessary to simplify the component stack handling to make way\nfor owner stacks. It also solves some hacks that we used to have but\ndon't quite make sense. It also solves the problem where things like key\nwarnings get silenced in RSC because they get deduped. It also surfaces\nareas where we were missing key warnings to begin with.\n\nAlmost every type of warning is issued from the renderer. React Elements\nare really not anything special themselves. They're just lazily invoked\nfunctions and its really the renderer that determines there semantics.\n\nWe have three types of warnings that previously fired in\nJSX/createElement:\n\n- Fragment props validation.\n- Type validation.\n- Key warning.\n\nIt's nice to be able to do some validation in the JSX/createElement\nbecause it has a more specific stack frame at the callsite. However,\nthat's the case for every type of component and validation. That's the\nwhole point of enableOwnerStacks. It's also not sufficient to do it in\nJSX/createElement so we also have validation in the renderers too. So\nthis validation is really just an eager validation but also happens\nagain later.\n\nThe problem with these is that we don't really know what types are valid\nuntil we get to the renderer. Additionally, by placing it in the\nisomorphic code it becomes harder to do deduping of warnings in a way\nthat makes sense for that renderer. It also means we can't reuse logic\nfor managing stacks etc.\n\nFragment props validation really should just be part of the renderer\nlike any other component type. This also matters once we add Fragment\nrefs and other fragment features. So I moved this into Fiber. However,\nsince some Fragments don't have Fibers, I do the validation in\nChildFiber instead of beginWork where it would normally happen.\n\nFor `type` validation we already do validation when rendering. By\nleaving it to the renderer we don't have to hard code an extra list.\nThis list also varies by context. E.g. class components aren't allowed\nin RSC but client references are but we don't have an isomorphic way to\nidentify client references because they're defined by the host config so\nthe current logic is flawed anyway. I kept the early validation for now\nwithout the `enableOwnerStacks` since it does provide a nicer stack\nframe but with that flag on it'll be handled with nice stacks anyway. I\nnormalized some of the errors to ensure tests pass.\n\nFor `key` validation it's the same principle. The mechanism for the\nheuristic is still the same - if it passes statically through a parent\nJSX/createElement call then it's considered validated. We already did\nprint the error later from the renderer so this also disables the early\nlog in the `enableOwnerStacks` flag.\n\nI also added logging to Fizz so that key warnings can print in SSR logs.\n\nFlight is a bit more complex. For elements that end up on the client we\njust pass the `validated` flag along to the client and let the client\nrenderer print the error once rendered. For server components we log the\nerror from Flight with the server component as the owner on the stack\nwhich will allow us to print the right stack for context. The factoring\nof this is a little tricky because we only want to warn if it's in an\narray parent but we want to log the error later to get the right debug\ninfo.\n\nFiber/Fizz has a similar factoring problem that causes us to create a\nfake Fiber for the owner which means the logs won't be associated with\nthe right place in DevTools.\n\nDiffTrain build for commit https://github.com/facebook/react/commit/84239da896fd7395a667ab1e7ef1ef338a32de8f.","shortMessageHtmlLink":"Move createElement/JSX Warnings into the Renderer (#29088)"}},{"before":"5fe8c0b4ecd09cfd2c0e1422089e2c603d558ff8","after":"84239da896fd7395a667ab1e7ef1ef338a32de8f","ref":"refs/heads/main","pushedAt":"2024-05-23T16:48:58.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"sebmarkbage","name":"Sebastian Markbåge","path":"/sebmarkbage","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/63648?s=80&v=4"},"commit":{"message":"Move createElement/JSX Warnings into the Renderer (#29088)\n\nThis is necessary to simplify the component stack handling to make way\r\nfor owner stacks. It also solves some hacks that we used to have but\r\ndon't quite make sense. It also solves the problem where things like key\r\nwarnings get silenced in RSC because they get deduped. It also surfaces\r\nareas where we were missing key warnings to begin with.\r\n\r\nAlmost every type of warning is issued from the renderer. React Elements\r\nare really not anything special themselves. They're just lazily invoked\r\nfunctions and its really the renderer that determines there semantics.\r\n\r\nWe have three types of warnings that previously fired in\r\nJSX/createElement:\r\n\r\n- Fragment props validation.\r\n- Type validation.\r\n- Key warning.\r\n\r\nIt's nice to be able to do some validation in the JSX/createElement\r\nbecause it has a more specific stack frame at the callsite. However,\r\nthat's the case for every type of component and validation. That's the\r\nwhole point of enableOwnerStacks. It's also not sufficient to do it in\r\nJSX/createElement so we also have validation in the renderers too. So\r\nthis validation is really just an eager validation but also happens\r\nagain later.\r\n\r\nThe problem with these is that we don't really know what types are valid\r\nuntil we get to the renderer. Additionally, by placing it in the\r\nisomorphic code it becomes harder to do deduping of warnings in a way\r\nthat makes sense for that renderer. It also means we can't reuse logic\r\nfor managing stacks etc.\r\n\r\nFragment props validation really should just be part of the renderer\r\nlike any other component type. This also matters once we add Fragment\r\nrefs and other fragment features. So I moved this into Fiber. However,\r\nsince some Fragments don't have Fibers, I do the validation in\r\nChildFiber instead of beginWork where it would normally happen.\r\n\r\nFor `type` validation we already do validation when rendering. By\r\nleaving it to the renderer we don't have to hard code an extra list.\r\nThis list also varies by context. E.g. class components aren't allowed\r\nin RSC but client references are but we don't have an isomorphic way to\r\nidentify client references because they're defined by the host config so\r\nthe current logic is flawed anyway. I kept the early validation for now\r\nwithout the `enableOwnerStacks` since it does provide a nicer stack\r\nframe but with that flag on it'll be handled with nice stacks anyway. I\r\nnormalized some of the errors to ensure tests pass.\r\n\r\nFor `key` validation it's the same principle. The mechanism for the\r\nheuristic is still the same - if it passes statically through a parent\r\nJSX/createElement call then it's considered validated. We already did\r\nprint the error later from the renderer so this also disables the early\r\nlog in the `enableOwnerStacks` flag.\r\n\r\nI also added logging to Fizz so that key warnings can print in SSR logs.\r\n\r\nFlight is a bit more complex. For elements that end up on the client we\r\njust pass the `validated` flag along to the client and let the client\r\nrenderer print the error once rendered. For server components we log the\r\nerror from Flight with the server component as the owner on the stack\r\nwhich will allow us to print the right stack for context. The factoring\r\nof this is a little tricky because we only want to warn if it's in an\r\narray parent but we want to log the error later to get the right debug\r\ninfo.\r\n\r\nFiber/Fizz has a similar factoring problem that causes us to create a\r\nfake Fiber for the owner which means the logs won't be associated with\r\nthe right place in DevTools.","shortMessageHtmlLink":"Move createElement/JSX Warnings into the Renderer (#29088)"}},{"before":"89d5de9d7e9dfc92bc17332dae932311a3290836","after":"2de2c20e92164b55aa4e17dfee33489eeff7ad88","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-05-23T16:45:24.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Set the current fiber to the source of the error during error reporting (#29044)\n\nThis lets us expose the component stack to the error reporting that\nhappens here as `console.error` patching. Now if you just call\n`console.error` in the error handlers it'll get the component stack\nadded to the end by React DevTools.\n\nHowever, unfortunately this happens a little too late so the Fiber will\nbe disconnected with its `.return` pointer set to null already. So it'll\nbe too late to extract a parent component stack from but you can at\nleast get the stack from source to error boundary. To work around this I\nmanually add the parent component stack in our default handlers when\nowner stacks are off. We could potentially fix this but you can also\njust include it yourself if you're calling `console.error` and it's not\na problem for owner stacks.\n\nThis is not a problem for owner stacks because we'll still have those\nand so for those just calling `console.error` just works. However, the\nmain feature is that by letting React add them, we can switch to using\nnative error stacks when available.\n\nDiffTrain build for [2e540e22b2b4038a278b2875306976b016fb31a9](https://github.com/facebook/react/commit/2e540e22b2b4038a278b2875306976b016fb31a9)","shortMessageHtmlLink":"Set the current fiber to the source of the error during error reporti…"}},{"before":"4313bf3f0dfc5823d556c8e0d2933c1ea2773e08","after":null,"ref":"refs/heads/gh/josephsavona/15/orig","pushedAt":"2024-05-23T16:45:16.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"}},{"before":"919c68bd6151d5d3e92ac99ca2ca000056876063","after":null,"ref":"refs/heads/gh/josephsavona/15/head","pushedAt":"2024-05-23T16:45:16.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"}},{"before":"919c68bd6151d5d3e92ac99ca2ca000056876063","after":null,"ref":"refs/heads/gh/josephsavona/15/base","pushedAt":"2024-05-23T16:45:16.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"}},{"before":"e85b9d23fcdcf9939b4cab16a5dae5d9d4c8e7a9","after":null,"ref":"refs/heads/gh/josephsavona/9/orig","pushedAt":"2024-05-23T16:45:13.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"}},{"before":"6d4f5c8a3579108da5ccddffad17ceb1467a97a4","after":null,"ref":"refs/heads/gh/josephsavona/9/head","pushedAt":"2024-05-23T16:45:13.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"}},{"before":"6d4f5c8a3579108da5ccddffad17ceb1467a97a4","after":null,"ref":"refs/heads/gh/josephsavona/9/base","pushedAt":"2024-05-23T16:45:13.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"}},{"before":"36160af3177b5eabea40b4227feb3fa913f364ba","after":null,"ref":"refs/heads/gh/josephsavona/8/orig","pushedAt":"2024-05-23T16:45:11.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"}},{"before":"ce4e19d0ec047172a1d15423e8453a40e2f172b5","after":null,"ref":"refs/heads/gh/josephsavona/8/head","pushedAt":"2024-05-23T16:45:11.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"}},{"before":"ce4e19d0ec047172a1d15423e8453a40e2f172b5","after":null,"ref":"refs/heads/gh/josephsavona/8/base","pushedAt":"2024-05-23T16:45:11.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"}},{"before":"3ed409d84b72eb5ee623813d737b9edcc43d7936","after":null,"ref":"refs/heads/gh/josephsavona/7/orig","pushedAt":"2024-05-23T16:45:08.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"}},{"before":"9c54058a5f4b4df576226079a999f27b1f40b918","after":null,"ref":"refs/heads/gh/josephsavona/7/head","pushedAt":"2024-05-23T16:45:08.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"}},{"before":"9c54058a5f4b4df576226079a999f27b1f40b918","after":null,"ref":"refs/heads/gh/josephsavona/7/base","pushedAt":"2024-05-23T16:45:08.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"}},{"before":"2e540e22b2b4038a278b2875306976b016fb31a9","after":"5fe8c0b4ecd09cfd2c0e1422089e2c603d558ff8","ref":"refs/heads/main","pushedAt":"2024-05-23T16:45:06.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"},"commit":{"message":"compiler: repro for unmerged scopes due to intermediates\n\nRepro of a case where we should ideally merge consecutive scopes, but where intermediate temporaries prevent the scopes from merging.\n\nWe'd need to reorder instructions in order to merge these.\n\nghstack-source-id: 4f05672604eeb547fc6c26ef99db6572843ac646\nPull Request resolved: https://github.com/facebook/react/pull/29197","shortMessageHtmlLink":"compiler: repro for unmerged scopes due to intermediates"}},{"before":"f7bd8a8abd077f826674309e214dc04c5dbcc0ce","after":"919c68bd6151d5d3e92ac99ca2ca000056876063","ref":"refs/heads/gh/josephsavona/15/base","pushedAt":"2024-05-23T16:45:04.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"},"commit":{"message":"Update on \"compiler: repro for unmerged scopes due to intermediates\"\n\n\nRepro of a case where we should ideally merge consecutive scopes, but where intermediate temporaries prevent the scopes from merging.\n\nWe'd need to reorder instructions in order to merge these.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"compiler: repro for unmerged scopes due to intermediates\""}},{"before":"af068bb60c191d61285c71372317521ba9c7b893","after":"6d4f5c8a3579108da5ccddffad17ceb1467a97a4","ref":"refs/heads/gh/josephsavona/9/base","pushedAt":"2024-05-23T16:45:02.000Z","pushType":"push","commitsCount":8,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"},"commit":{"message":"Update on \"compiler: Use types to decide which scopes are eligible for merging\"\n\n\r\nIn MergeReactiveScopesThatInvalidateTogether when deciding which scopes were eligible for merging, we previously looked specifically at the type of the instruction whose lvalue is declaration. So if a scope declaration was `t0`, we'd look for the instruction where `t0` was the lvalue and look at the instruction type to decide if it is eligible for merging.\r\n\r\nHere, we use the inferred type instead (now that the inferred types support the same set of types of instructions we looked at before). This allows us to find more cases where scopes can be merged.\r\n\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"compiler: Use types to decide which scopes are eligible fo…"}},{"before":"8d9332afd491abcff5abf86b4c6ef25b95eb6787","after":"ce4e19d0ec047172a1d15423e8453a40e2f172b5","ref":"refs/heads/gh/josephsavona/8/base","pushedAt":"2024-05-23T16:44:59.000Z","pushType":"push","commitsCount":7,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"},"commit":{"message":"Update on \"compiler: Improve merging of memo scopes that invalidate together\"\n\n\nImproves merging of consecutive scopes so that we now merge two scopes if the dependencies of the second scope are a subset of the previous scope's output *and* that dependency has a type that will always produce a new value (array, object, jsx, function) if it is re-evaluated.\n\nTo make this easier, we extend the set of builtin types to include ones for function expressions and JSX and to infer these types in InferTypes. This allows using the already inferred types in MergeReactiveScopesThatInvalidateTogether.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"compiler: Improve merging of memo scopes that invalidate t…"}},{"before":"812c9902a562161bc6d3fe8cff32d4a19dab7de7","after":"9c54058a5f4b4df576226079a999f27b1f40b918","ref":"refs/heads/gh/josephsavona/7/base","pushedAt":"2024-05-23T16:44:58.000Z","pushType":"push","commitsCount":6,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"},"commit":{"message":"Update on \"compiler: fixture for suboptimal jsx sibling memo block merging\"\n\n\nReact Compiler attempts to merge consecutive reactive scopes in order to reduce overhead. The basic idea is that if two consecutive scopes would always invalidate together then we should merge them. It gets more complicated, though, because values produced by the earlier scope may not always invalidate when their inputs do. For example, a scope that produces `fn(x)` may not invalidate on all changes to `x` if the function is `Math.max(x, 10)` (changing x from 8 to 9 won't change the output).\n\nPreviously we were conservative and only merged if either:\n* the two scopes had the same dependencies\n* the second scope's deps exactly matched the previous scope's outputs.\n\nYou can see this in the new fixture, where the second `