Skip to content

[compiler] Rename mismatched variable names after type changes#600

Closed
everettbu wants to merge 1 commit into
mainfrom
pr35883
Closed

[compiler] Rename mismatched variable names after type changes#600
everettbu wants to merge 1 commit into
mainfrom
pr35883

Conversation

@everettbu

@everettbu everettbu commented Feb 23, 2026

Copy link
Copy Markdown

Mirror of facebook/react#35883
Original author: josephsavona


Rename state: Environment to env: Environment in
ValidateMemoizedEffectDependencies visitor methods, and
errorState: Environment to env: Environment in
ValidatePreservedManualMemoization's validateInferredDep.


Stack created with Sapling. Best reviewed with ReviewStack.

  • #35888
  • #35884
  • -> #35883
  • #35882
  • #35881
  • #35880
  • #35879
  • #35878
  • #35877
  • #35876
  • #35875
  • #35874

@everettbu everettbu added CLA Signed React Core Team Opened by a member of the React Core Team labels Feb 23, 2026
@greptile-apps

greptile-apps Bot commented Feb 23, 2026

Copy link
Copy Markdown

Greptile Summary

Renames the errorState: Environment parameter to env: Environment in the validateInferredDep function within ValidatePreservedManualMemoization.ts, and updates the single usage site accordingly. This is a pure rename for consistency with naming conventions used elsewhere in the validation modules (all other validation functions already use env for the Environment parameter). No behavioral changes.

Confidence Score: 5/5

  • This PR is safe to merge — it is a purely mechanical variable rename with no behavioral changes.
  • The change renames a single parameter and its one usage site. There are no remaining references to the old name, the call site already passes state.env, and the types are unchanged. Zero risk of regression.
  • No files require special attention.

Important Files Changed

Filename Overview
compiler/packages/babel-plugin-react-compiler/src/Validation/ValidatePreservedManualMemoization.ts Simple parameter rename from errorState to env in validateInferredDep, with corresponding usage update. No behavioral changes.

Last reviewed commit: 8efe0fc

@greptile-apps greptile-apps Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

79 files reviewed, 1 comment

Edit Code Review Agent Settings | Greptile

Comment on lines +737 to +743
if (this.logger != null) {
this.logger.logEvent(this.filename, {
kind: 'CompileError',
detail: error,
fnLoc: null,
});
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duplicate error logging with fnLoc: null

recordError logs a CompileError event here with fnLoc: null, but errors accumulated via this path are also logged again by logError() in Program.ts:180-189 (which iterates over err.details and logs each with the real fnLoc). This causes duplicate log entries for the same error — visible in the dynamic-gating-bailout-nopanic.expect.md test output, which now shows two CompileError JSON entries for the same diagnostic (one with "fnLoc":null and one with the actual location).

Is the intent to have early per-error logging here (for streaming diagnostics), with the Program.ts logging being a redundant legacy path that should be removed? Or should this logging be removed from recordError to avoid duplicates?

Prompt To Fix With AI
This is a comment left during a code review.
Path: compiler/packages/babel-plugin-react-compiler/src/HIR/Environment.ts
Line: 737-743

Comment:
**Duplicate error logging with `fnLoc: null`**

`recordError` logs a `CompileError` event here with `fnLoc: null`, but errors accumulated via this path are also logged again by `logError()` in `Program.ts:180-189` (which iterates over `err.details` and logs each with the real `fnLoc`). This causes duplicate log entries for the same error — visible in the `dynamic-gating-bailout-nopanic.expect.md` test output, which now shows two `CompileError` JSON entries for the same diagnostic (one with `"fnLoc":null` and one with the actual location).

Is the intent to have early per-error logging here (for streaming diagnostics), with the `Program.ts` logging being a redundant legacy path that should be removed? Or should this logging be removed from `recordError` to avoid duplicates?

How can I resolve this? If you propose a fix, please make it concise.

@greptile-apps greptile-apps Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

79 files reviewed, no comments

Edit Code Review Agent Settings | Greptile

@greptile-apps greptile-apps Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

78 files reviewed, no comments

Edit Code Review Agent Settings | Greptile

@greptile-apps greptile-apps Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

78 files reviewed, no comments

Edit Code Review Agent Settings | Greptile

@greptile-apps greptile-apps Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

78 files reviewed, no comments

Edit Code Review Agent Settings | Greptile

Rename `state: Environment` to `env: Environment` in
ValidateMemoizedEffectDependencies visitor methods, and
`errorState: Environment` to `env: Environment` in
ValidatePreservedManualMemoization's validateInferredDep.

@greptile-apps greptile-apps Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 file reviewed, no comments

Edit Code Review Agent Settings | Greptile

@everettbu

Copy link
Copy Markdown
Author

Upstream PR was closed or merged. Code is synced via branch mirror.

@everettbu everettbu closed this Feb 24, 2026
@everettbu
everettbu deleted the pr35883 branch February 24, 2026 00:36
@everettbu
everettbu restored the pr35883 branch February 24, 2026 01:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed React Core Team Opened by a member of the React Core Team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants