Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[compiler] Represent array accesses with PropertyLoad #32287

Merged
merged 1 commit into from
Feb 18, 2025
Merged

[compiler] Represent array accesses with PropertyLoad #32287

merged 1 commit into from
Feb 18, 2025

Conversation

mofeiZ
Copy link
Contributor

@mofeiZ mofeiZ commented Feb 1, 2025

Prior to this PR, our HIR represented property access with numeric literals (e.g. myVar[0]) as ComputedLoads. This means that they were subject to some deopts (most notably, not being easily dedupable / hoistable as dependencies).

Now, PropertyLoad, PropertyStore, etc reference numeric and string literals (although not yet string literals that aren't valid babel identifiers). The difference between PropertyLoad and ComputedLoad is fuzzy now (maybe we should rename these).

  • PropertyLoad: property keys are string and numeric literals, only when the string literals are valid babel identifiers
  • ComputedLoad: non-valid babel identifier string literals (rare) and other non-literal expressions

The biggest feature from this PR is that it trivially enables array-indicing expressions as dependencies. The compiler can also specify global and imported types for arrays (e.g. return value of useState)

I'm happy to close this if it complicates more than it helps -- alternative options are to entirely rely on instruction reordering-based approaches like ReactiveGraphIR or make dependency-specific parsing + hoisting logic more robust.

@josephsavona
Copy link
Contributor

Didn’t look at the code yet but the idea makes totally sense. PropertyLoad for cases of a static property, ComputedLoad for where the index is dynamic. We might want to rename them in a follow up.

Caner452

This comment was marked as spam.

Comment on lines +1510 to +1511
const opaquePropertyLiteral = Symbol();
export type PropertyLiteral = (string | number) & {
[opaquePropertyLiteral]: 'PropertyLiteral';
};
export function makePropertyLiteral(value: string | number): PropertyLiteral {
return value as PropertyLiteral;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the primary change: all 'static' instructions (PropertyLoad, PropertyStore, and PropertyDelete) can now operate on either string or numeric indices

@mofeiZ mofeiZ force-pushed the pr32287 branch 2 times, most recently from 4b2fbd9 to 0aadfc5 Compare February 18, 2025 16:34
mofeiZ added a commit that referenced this pull request Feb 18, 2025
This removes special casing for `PropertyStore` mutability inference
within FunctionExpressions.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32097).
* #32287
* #32104
* #32098
* __->__ #32097
mofeiZ added a commit that referenced this pull request Feb 18, 2025
(title)
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32098).
* #32287
* #32104
* __->__ #32098
* #32097
mofeiZ added a commit that referenced this pull request Feb 18, 2025
(title)
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32104).
* #32287
* __->__ #32104
* #32098
* #32097
Prior to this PR, our HIR represented property access with numeric literals (e.g. `myVar[0]`) as ComputedLoads. This means that they were subject to some deopts (most notably, not being easily dedupable / hoistable as dependencies).

Now, `PropertyLoad`, `PropertyStore`, etc reference numeric and string literals (although not yet string literals that aren't valid babel identifiers). The difference between PropertyLoad and ComputedLoad is fuzzy now (maybe we should rename these).
- PropertyLoad: property keys are string and numeric literals, only when the string literals are valid babel identifiers
- ComputedLoad: non-valid babel identifier string literals (rare) and other non-literal expressions

The biggest feature from this PR is that it trivially enables array-indicing expressions as dependencies. The compiler can also specify global and imported types for arrays (e.g. return value of `useState`)


I'm happy to close this if it complicates more than it helps -- alternative options are to entirely rely on instruction reordering-based approaches like ReactiveGraphIR or make dependency-specific parsing + hoisting logic more robust.
@mofeiZ mofeiZ merged commit a9575dc into main Feb 18, 2025
22 checks passed
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.

4 participants