{"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:1717196691.0","currentOid":""},"activityList":{"items":[{"before":"23fac22ae26e7005a81822d51c1bd95bb314726a","after":"84fea4d26fee6e46604ba39101654bc0fd3d4448","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-05-31T23:20:42.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":"Bump version to 0.0.0-experimental-7054a14-20240601\n\nDiffTrain build for [d77dd31a329df55a051800fc76668af8da8332b4](https://github.com/facebook/react/commit/d77dd31a329df55a051800fc76668af8da8332b4)","shortMessageHtmlLink":"Bump version to 0.0.0-experimental-7054a14-20240601"}},{"before":"fc83ec724438dc7cc1bfed9a1ed205def5b9c53f","after":"9e1cf0f3f13ec316369d512c6d5dafe16b97ab6c","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-31T23:20:33.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":"Bump version to 0.0.0-experimental-7054a14-20240601\n\nDiffTrain build for commit https://github.com/facebook/react/commit/d77dd31a329df55a051800fc76668af8da8332b4.","shortMessageHtmlLink":"Bump version to 0.0.0-experimental-7054a14-20240601"}},{"before":"113c8e7f72bcf5d3bc285546da1508b45da3cf53","after":"d77dd31a329df55a051800fc76668af8da8332b4","ref":"refs/heads/main","pushedAt":"2024-05-31T23:15:49.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"poteto","name":"lauren","path":"/poteto","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1390709?s=80&v=4"},"commit":{"message":"Bump version to 0.0.0-experimental-7054a14-20240601","shortMessageHtmlLink":"Bump version to 0.0.0-experimental-7054a14-20240601"}},{"before":"4ca23423317c28ba62e9dff859ff115897362b06","after":"23fac22ae26e7005a81822d51c1bd95bb314726a","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-05-31T23:09:34.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":"[compiler:eslint] Don't crash if hermes parser fails to parse\n\nEslint rules should never throw, so if we fail to parse with Babel or\nHermes, we should just ignore the error. This should fix issues such as\ntrying to run the eslint rule on non tsx|ts|jsx|js files, Hermes parser\nnot supporting certain JS syntax, etc.\n\nI didn't add a test for this as our eslint-rule-tester config uses\nhermes-eslint parser, so it wasn't possible to add a top level await as\nit would crash hermes-eslint before our rule was triggered. Similarly I\ncouldn't add a test for non-JS files as it would not be parseable by\nhermes-eslint.\n\nFixes #29107\n\nghstack-source-id: 60afcdb89ab4a8d2e4697cc50c5490803e7cbeac\nPull Request resolved: https://github.com/facebook/react/pull/29631\n\nDiffTrain build for [113c8e7f72bcf5d3bc285546da1508b45da3cf53](https://github.com/facebook/react/commit/113c8e7f72bcf5d3bc285546da1508b45da3cf53)","shortMessageHtmlLink":"[compiler:eslint] Don't crash if hermes parser fails to parse"}},{"before":"9f66192fd2d91882968ebe2c2e13f7018c6232cb","after":"fc83ec724438dc7cc1bfed9a1ed205def5b9c53f","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-31T23:09:32.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":"[compiler:eslint] Don't crash if hermes parser fails to parse\n\nEslint rules should never throw, so if we fail to parse with Babel or\nHermes, we should just ignore the error. This should fix issues such as\ntrying to run the eslint rule on non tsx|ts|jsx|js files, Hermes parser\nnot supporting certain JS syntax, etc.\n\nI didn't add a test for this as our eslint-rule-tester config uses\nhermes-eslint parser, so it wasn't possible to add a top level await as\nit would crash hermes-eslint before our rule was triggered. Similarly I\ncouldn't add a test for non-JS files as it would not be parseable by\nhermes-eslint.\n\nFixes #29107\n\nghstack-source-id: 60afcdb89ab4a8d2e4697cc50c5490803e7cbeac\nPull Request resolved: https://github.com/facebook/react/pull/29631\n\nDiffTrain build for commit https://github.com/facebook/react/commit/113c8e7f72bcf5d3bc285546da1508b45da3cf53.","shortMessageHtmlLink":"[compiler:eslint] Don't crash if hermes parser fails to parse"}},{"before":"a943066fabf8d55459c4cbab8c5d81b15ab3094e","after":null,"ref":"refs/heads/gh/poteto/17/orig","pushedAt":"2024-05-31T23:04:51.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"poteto","name":"lauren","path":"/poteto","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1390709?s=80&v=4"}},{"before":"a05ad3eee3026607240a598ce5782bf6d095b879","after":null,"ref":"refs/heads/gh/poteto/17/head","pushedAt":"2024-05-31T23:04:51.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"poteto","name":"lauren","path":"/poteto","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1390709?s=80&v=4"}},{"before":"a05ad3eee3026607240a598ce5782bf6d095b879","after":null,"ref":"refs/heads/gh/poteto/17/base","pushedAt":"2024-05-31T23:04:51.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"poteto","name":"lauren","path":"/poteto","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1390709?s=80&v=4"}},{"before":"adbec0c25aff07f04b0678679554505ba2813168","after":"113c8e7f72bcf5d3bc285546da1508b45da3cf53","ref":"refs/heads/main","pushedAt":"2024-05-31T23:04:48.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"poteto","name":"lauren","path":"/poteto","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1390709?s=80&v=4"},"commit":{"message":"[compiler:eslint] Don't crash if hermes parser fails to parse\n\nEslint rules should never throw, so if we fail to parse with Babel or\nHermes, we should just ignore the error. This should fix issues such as\ntrying to run the eslint rule on non tsx|ts|jsx|js files, Hermes parser\nnot supporting certain JS syntax, etc.\n\nI didn't add a test for this as our eslint-rule-tester config uses\nhermes-eslint parser, so it wasn't possible to add a top level await as\nit would crash hermes-eslint before our rule was triggered. Similarly I\ncouldn't add a test for non-JS files as it would not be parseable by\nhermes-eslint.\n\nFixes #29107\n\nghstack-source-id: 60afcdb89ab4a8d2e4697cc50c5490803e7cbeac\nPull Request resolved: https://github.com/facebook/react/pull/29631","shortMessageHtmlLink":"[compiler:eslint] Don't crash if hermes parser fails to parse"}},{"before":"861af3e56d6c1f113d07342b0eee2fbcee1a2046","after":"a05ad3eee3026607240a598ce5782bf6d095b879","ref":"refs/heads/gh/poteto/17/base","pushedAt":"2024-05-31T23:04:44.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"poteto","name":"lauren","path":"/poteto","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1390709?s=80&v=4"},"commit":{"message":"Update\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update"}},{"before":"6ce16b6bb01fe4f73310fac2a880d69f890dd8b2","after":"9f66192fd2d91882968ebe2c2e13f7018c6232cb","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-31T21:58:00.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: `useTransition` after `use` gets stuck in pending state (#29670)\n\nWhen a component suspends with `use`, we switch to the \"re-render\"\ndispatcher during the subsequent render attempt, so that we can reuse\nthe work from the initial attempt. However, once we run out of hooks\nfrom the previous attempt, we should switch back to the regular \"update\"\ndispatcher.\n\nThis is conceptually the same fix as the one introduced in\nhttps://github.com/facebook/react/pull/26232. That fix only accounted\nfor initial mount, but the useTransition regression test added in\nf82973302b3f490ec120c3b102e8c3792452dfc9 illustrates that we need to\nhandle updates, too.\n\nThe issue affects more than just useTransition but because most of the\nbehavior between the \"re-render\" and \"update\" dispatchers is the same\nit's hard to contrive other scenarios in a test, which is probably why\nit took so long for someone to notice.\n\nCloses #28923 and #29209\n\n---------\n\nCo-authored-by: eps1lon <sebastian.silbermann@vercel.com>\n\nDiffTrain build for commit https://github.com/facebook/react/commit/adbec0c25aff07f04b0678679554505ba2813168.","shortMessageHtmlLink":"Fix: <code>useTransition</code> after <code>use</code> gets stuck in pending state (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2326130385\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/29670\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/29670/hovercard\" href=\"https://github.com/facebook/react/pull/29670\">#29670</a>)"}},{"before":"11f55031dd3f018db15813d2df9e27d5347b204e","after":"4ca23423317c28ba62e9dff859ff115897362b06","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-05-31T21:57:53.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: `useTransition` after `use` gets stuck in pending state (#29670)\n\nWhen a component suspends with `use`, we switch to the \"re-render\"\ndispatcher during the subsequent render attempt, so that we can reuse\nthe work from the initial attempt. However, once we run out of hooks\nfrom the previous attempt, we should switch back to the regular \"update\"\ndispatcher.\n\nThis is conceptually the same fix as the one introduced in\nhttps://github.com/facebook/react/pull/26232. That fix only accounted\nfor initial mount, but the useTransition regression test added in\nf82973302b3f490ec120c3b102e8c3792452dfc9 illustrates that we need to\nhandle updates, too.\n\nThe issue affects more than just useTransition but because most of the\nbehavior between the \"re-render\" and \"update\" dispatchers is the same\nit's hard to contrive other scenarios in a test, which is probably why\nit took so long for someone to notice.\n\nCloses #28923 and #29209\n\n---------\n\nCo-authored-by: eps1lon <sebastian.silbermann@vercel.com>\n\nDiffTrain build for [adbec0c25aff07f04b0678679554505ba2813168](https://github.com/facebook/react/commit/adbec0c25aff07f04b0678679554505ba2813168)","shortMessageHtmlLink":"Fix: <code>useTransition</code> after <code>use</code> gets stuck in pending state (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2326130385\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/29670\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/29670/hovercard\" href=\"https://github.com/facebook/react/pull/29670\">#29670</a>)"}},{"before":"ec6fe57a5027d60a959493a2e44b6872b8de0ab8","after":"adbec0c25aff07f04b0678679554505ba2813168","ref":"refs/heads/main","pushedAt":"2024-05-31T21:52:47.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: `useTransition` after `use` gets stuck in pending state (#29670)\n\nWhen a component suspends with `use`, we switch to the \"re-render\"\r\ndispatcher during the subsequent render attempt, so that we can reuse\r\nthe work from the initial attempt. However, once we run out of hooks\r\nfrom the previous attempt, we should switch back to the regular \"update\"\r\ndispatcher.\r\n\r\nThis is conceptually the same fix as the one introduced in\r\nhttps://github.com/facebook/react/pull/26232. That fix only accounted\r\nfor initial mount, but the useTransition regression test added in\r\nf82973302b3f490ec120c3b102e8c3792452dfc9 illustrates that we need to\r\nhandle updates, too.\r\n\r\nThe issue affects more than just useTransition but because most of the\r\nbehavior between the \"re-render\" and \"update\" dispatchers is the same\r\nit's hard to contrive other scenarios in a test, which is probably why\r\nit took so long for someone to notice.\r\n\r\nCloses #28923 and #29209\r\n\r\n---------\r\n\r\nCo-authored-by: eps1lon <sebastian.silbermann@vercel.com>","shortMessageHtmlLink":"Fix: <code>useTransition</code> after <code>use</code> gets stuck in pending state (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2326130385\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/29670\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/29670/hovercard\" href=\"https://github.com/facebook/react/pull/29670\">#29670</a>)"}},{"before":"c01853d37084c038240e9ca8fba5db45f91fd2db","after":"11f55031dd3f018db15813d2df9e27d5347b204e","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-05-31T21:15: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":"[compiler] Prune dependencies that are only used by useRef or useState\n\nSummary: jmbrown215 recently had an observation that the arguments to useState/useRef are only used when a component renders for the first time, and never afterwards. We can skip more computation that we previously could, with reactive blocks that previously recomputed values when inputs changed now only ever computing them on the first render.\n\nghstack-source-id: 5d044ef787a7da901c70990f4399aa90c9b96802\nPull Request resolved: https://github.com/facebook/react/pull/29653\n\nDiffTrain build for [c69211a9dfa683038b1a758aba2ca09c7862a6d3](https://github.com/facebook/react/commit/c69211a9dfa683038b1a758aba2ca09c7862a6d3)","shortMessageHtmlLink":"[compiler] Prune dependencies that are only used by useRef or useState"}},{"before":"93f1aac38ad2a92b2de964c063867c84f3c3819c","after":"6ce16b6bb01fe4f73310fac2a880d69f890dd8b2","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-31T21:15:31.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":"[compiler] Debug tool to emit change detection code rather than memoization\n\nSummary: The essential assumption of the compiler is that if the inputs to a computation have not changed, then the output should not change either--computation that the compiler optimizes is idempotent.\n\nThis is, of course, known to be false in practice, because this property rests on requirements (the Rules of React) that are loosely enforced at best. When rolling out the compiler to a codebase that might have rules of react violations, how should developers debug any issues that arise?\n\nThis diff attempts one approach to that: when the option is set, rather than simply skipping computation when dependencies haven't changed, we will *still perform the computation*, but will then use a runtime function to compare the original value and the resultant value. The runtime function can be customized, but the idea is that it will perform a structural equality check on the values, and if the values aren't structurally equal, we can report an error, including information about what file and what variable was to blame.\n\nThis assists in debugging by narrowing down what specific computation is responsible for a difference in behavior between the uncompiled code and the program after compilation.\n\nghstack-source-id: 50dad3dacfc7fef74be350431aa2ebf5e9cb0031\nPull Request resolved: https://github.com/facebook/react/pull/29656\n\nDiffTrain build for commit https://github.com/facebook/react/commit/5c420e3824859b33321b4bc9ce3119806fac56c2.","shortMessageHtmlLink":"[compiler] Debug tool to emit change detection code rather than memoi…"}},{"before":"df9d22ca693225914a6ff460bdf82c75f3b7041b","after":"93f1aac38ad2a92b2de964c063867c84f3c3819c","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-31T21:14:46.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":"[compiler] Recompute values every time\n\nSummary: This PR expands the analysis from the previous in the stack in order to also capture when a value can incorrectly change within a single render, rather than just changing between two renders. In the case where dependencies have changed and so a new value is being computed, we now compute the value twice and compare the results. This would, for example, catch when we call Math.random() in render.\n\nThe generated code is a little convoluted, because we don't want to have to traverse the generated code and substitute variable names with new ones. Instead, we save the initial value to the cache as normal, then run the computation block again and compare the resulting values to the cached ones. Then, to make sure that the cached values are identical to the computed ones, we reassign the cached values into the output variables.\n\nghstack-source-id: d0f11a4cb2a612cbffdfdcaa9e75efbd6e38019f\nPull Request resolved: https://github.com/facebook/react/pull/29657\n\nDiffTrain build for commit https://github.com/facebook/react/commit/522d22f29904f2164210b3ae218b9b69b61e9a4c.","shortMessageHtmlLink":"[compiler] Recompute values every time"}},{"before":"e82072d2aa46e5e7251c7b64fbecef425c346092","after":"c01853d37084c038240e9ca8fba5db45f91fd2db","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-05-31T21:14:42.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":"[compiler] rfc: Include location information in identifiers and reactive scopes for debugging\n\nSummary: Using the change detection code to debug codebases that violate the rules of react is a lot easier when we have a source location corresponding to the value that has changed inappropriately. I didn't see an easy way to track that information in the existing data structures at the point of codegen, so this PR adds locations to identifiers and reactive scopes (the location of a reactive scope is the range of the locations of its included identifiers).\n\nI'm interested if there's a better way to do this that I missed!\n\nghstack-source-id: aed5f7eddae7256f41da4389e8f16fcb3daaee49\nPull Request resolved: https://github.com/facebook/react/pull/29658\n\nDiffTrain build for [ec6fe57a5027d60a959493a2e44b6872b8de0ab8](https://github.com/facebook/react/commit/ec6fe57a5027d60a959493a2e44b6872b8de0ab8)","shortMessageHtmlLink":"[compiler] rfc: Include location information in identifiers and react…"}},{"before":"f50a2312e15829c2c3ca6bc6b6e3136258dd1426","after":"df9d22ca693225914a6ff460bdf82c75f3b7041b","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-31T21:14:34.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":"[compiler] rfc: Include location information in identifiers and reactive scopes for debugging\n\nSummary: Using the change detection code to debug codebases that violate the rules of react is a lot easier when we have a source location corresponding to the value that has changed inappropriately. I didn't see an easy way to track that information in the existing data structures at the point of codegen, so this PR adds locations to identifiers and reactive scopes (the location of a reactive scope is the range of the locations of its included identifiers).\n\nI'm interested if there's a better way to do this that I missed!\n\nghstack-source-id: aed5f7eddae7256f41da4389e8f16fcb3daaee49\nPull Request resolved: https://github.com/facebook/react/pull/29658\n\nDiffTrain build for commit https://github.com/facebook/react/commit/ec6fe57a5027d60a959493a2e44b6872b8de0ab8.","shortMessageHtmlLink":"[compiler] rfc: Include location information in identifiers and react…"}},{"before":"f4e1d9ef039a183caa70b68a22d3f600a469ad15","after":"e82072d2aa46e5e7251c7b64fbecef425c346092","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-05-31T21:12: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":"[compiler] Option to always take the non-memo branch\n\nSummary: This adds a debugging mode to the compiler that simply adds a `|| true` to the guard on all memoization blocks, which results in the generated code never using memoized values and always recomputing them. This is designed as a validation tool for the compiler's correctness--every program *should* behave exactly the same with this option enabled as it would with it disabled, and so any difference in behavior should be investigated as either a compiler bug or a pipeline issue.\n\n(We add `|| true` rather than dropping the conditional block entirely because we still want to exercise the guard tests, in case the guards themselves are the source of an error, like reading a property from undefined in a guard.)\n\nghstack-source-id: 955a47ec1689842da82552225a19a1008c57fe2c\nPull Request resolved: https://github.com/facebook/react/pull/29655\n\nDiffTrain build for [8b01a2e0bf17adc6bb7b81d1d0063c7efe9ea8b1](https://github.com/facebook/react/commit/8b01a2e0bf17adc6bb7b81d1d0063c7efe9ea8b1)","shortMessageHtmlLink":"[compiler] Option to always take the non-memo branch"}},{"before":"d0d94923cd9e5ebf0df9c5941174755f23eac050","after":"f50a2312e15829c2c3ca6bc6b6e3136258dd1426","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-31T21:12: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":"[compiler] Option to always take the non-memo branch\n\nSummary: This adds a debugging mode to the compiler that simply adds a `|| true` to the guard on all memoization blocks, which results in the generated code never using memoized values and always recomputing them. This is designed as a validation tool for the compiler's correctness--every program *should* behave exactly the same with this option enabled as it would with it disabled, and so any difference in behavior should be investigated as either a compiler bug or a pipeline issue.\n\n(We add `|| true` rather than dropping the conditional block entirely because we still want to exercise the guard tests, in case the guards themselves are the source of an error, like reading a property from undefined in a guard.)\n\nghstack-source-id: 955a47ec1689842da82552225a19a1008c57fe2c\nPull Request resolved: https://github.com/facebook/react/pull/29655\n\nDiffTrain build for commit https://github.com/facebook/react/commit/8b01a2e0bf17adc6bb7b81d1d0063c7efe9ea8b1.","shortMessageHtmlLink":"[compiler] Option to always take the non-memo branch"}},{"before":"ec6fe57a5027d60a959493a2e44b6872b8de0ab8","after":null,"ref":"refs/heads/gh/mvitousek/5/orig","pushedAt":"2024-05-31T21:10:26.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"8dfb52d9290f5fb4c45ae47eba3d58a9a5b36646","after":null,"ref":"refs/heads/gh/mvitousek/5/head","pushedAt":"2024-05-31T21:10:26.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"8dfb52d9290f5fb4c45ae47eba3d58a9a5b36646","after":null,"ref":"refs/heads/gh/mvitousek/5/base","pushedAt":"2024-05-31T21:10:26.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"522d22f29904f2164210b3ae218b9b69b61e9a4c","after":"ec6fe57a5027d60a959493a2e44b6872b8de0ab8","ref":"refs/heads/main","pushedAt":"2024-05-31T21:09:35.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"[compiler] rfc: Include location information in identifiers and reactive scopes for debugging\n\nSummary: Using the change detection code to debug codebases that violate the rules of react is a lot easier when we have a source location corresponding to the value that has changed inappropriately. I didn't see an easy way to track that information in the existing data structures at the point of codegen, so this PR adds locations to identifiers and reactive scopes (the location of a reactive scope is the range of the locations of its included identifiers).\n\nI'm interested if there's a better way to do this that I missed!\n\nghstack-source-id: aed5f7eddae7256f41da4389e8f16fcb3daaee49\nPull Request resolved: https://github.com/facebook/react/pull/29658","shortMessageHtmlLink":"[compiler] rfc: Include location information in identifiers and react…"}},{"before":"ca6f9707e1707f26d0aa3f76663ec9dab2cec926","after":"8dfb52d9290f5fb4c45ae47eba3d58a9a5b36646","ref":"refs/heads/gh/mvitousek/5/base","pushedAt":"2024-05-31T21:08:57.000Z","pushType":"push","commitsCount":6,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update on \"[compiler] rfc: Include location information in identifiers and reactive scopes for debugging\"\n\n\nSummary: Using the change detection code to debug codebases that violate the rules of react is a lot easier when we have a source location corresponding to the value that has changed inappropriately. I didn't see an easy way to track that information in the existing data structures at the point of codegen, so this PR adds locations to identifiers and reactive scopes (the location of a reactive scope is the range of the locations of its included identifiers).\n\nI'm interested if there's a better way to do this that I missed!\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] rfc: Include location information in identifier…"}},{"before":"522d22f29904f2164210b3ae218b9b69b61e9a4c","after":null,"ref":"refs/heads/gh/mvitousek/4/orig","pushedAt":"2024-05-31T21:08:02.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"35c7b9ef1fbd2391d494108d0201f62545ed3e12","after":null,"ref":"refs/heads/gh/mvitousek/4/head","pushedAt":"2024-05-31T21:08:02.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"35c7b9ef1fbd2391d494108d0201f62545ed3e12","after":null,"ref":"refs/heads/gh/mvitousek/4/base","pushedAt":"2024-05-31T21:08:02.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"c69211a9dfa683038b1a758aba2ca09c7862a6d3","after":"522d22f29904f2164210b3ae218b9b69b61e9a4c","ref":"refs/heads/main","pushedAt":"2024-05-31T21:08:00.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"[compiler] Recompute values every time\n\nSummary: This PR expands the analysis from the previous in the stack in order to also capture when a value can incorrectly change within a single render, rather than just changing between two renders. In the case where dependencies have changed and so a new value is being computed, we now compute the value twice and compare the results. This would, for example, catch when we call Math.random() in render.\n\nThe generated code is a little convoluted, because we don't want to have to traverse the generated code and substitute variable names with new ones. Instead, we save the initial value to the cache as normal, then run the computation block again and compare the resulting values to the cached ones. Then, to make sure that the cached values are identical to the computed ones, we reassign the cached values into the output variables.\n\nghstack-source-id: d0f11a4cb2a612cbffdfdcaa9e75efbd6e38019f\nPull Request resolved: https://github.com/facebook/react/pull/29657","shortMessageHtmlLink":"[compiler] Recompute values every time"}},{"before":"594801ab0d490abfb21af3366cd5078098a316a7","after":"35c7b9ef1fbd2391d494108d0201f62545ed3e12","ref":"refs/heads/gh/mvitousek/4/base","pushedAt":"2024-05-31T21:07:58.000Z","pushType":"push","commitsCount":6,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update on \"[compiler] Recompute values every time\"\n\n\nSummary: This PR expands the analysis from the previous in the stack in order to also capture when a value can incorrectly change within a single render, rather than just changing between two renders. In the case where dependencies have changed and so a new value is being computed, we now compute the value twice and compare the results. This would, for example, catch when we call Math.random() in render.\n\nThe generated code is a little convoluted, because we don't want to have to traverse the generated code and substitute variable names with new ones. Instead, we save the initial value to the cache as normal, then run the computation block again and compare the resulting values to the cached ones. Then, to make sure that the cached values are identical to the computed ones, we reassign the cached values into the output variables.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Recompute values every time\""}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEWXXKMgA","startCursor":null,"endCursor":null}},"title":"Activity · facebook/react"}