Skip to content

refactor(ast, linter, semantic, transformer): replace Address::from_ref with UnstableAddress::unstable_address#15701

Merged
graphite-app[bot] merged 1 commit intomainfrom
11-13-refactor_ast_linter_semantic_transformer_replace_address_from_ref_with_unstableaddress_unstable_address_
Nov 14, 2025
Merged

refactor(ast, linter, semantic, transformer): replace Address::from_ref with UnstableAddress::unstable_address#15701
graphite-app[bot] merged 1 commit intomainfrom
11-13-refactor_ast_linter_semantic_transformer_replace_address_from_ref_with_unstableaddress_unstable_address_

Conversation

@overlookmotel
Copy link
Member

@overlookmotel overlookmotel commented Nov 14, 2025

Migrate all uses of Address::from_ptr and Address::from_ref to UnstableAddress::unstable_address across whole codebase, except for in oxc_traverse, which has particular requirements around aliasing, and can't use unstable_address.

This makes no difference to behavior or performance, it's just a more reliable API.

@github-actions github-actions bot added A-linter Area - Linter A-semantic Area - Semantic A-ast Area - AST A-transformer Area - Transformer / Transpiler A-ast-tools Area - AST tools labels Nov 14, 2025
Copy link
Member Author

overlookmotel commented Nov 14, 2025


How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

  • 0-merge - adds this PR to the back of the merge queue
  • hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

@github-actions github-actions bot added the C-cleanup Category - technical debt or refactoring. Solution not expected to change behavior label Nov 14, 2025
@codspeed-hq
Copy link

codspeed-hq bot commented Nov 14, 2025

CodSpeed Performance Report

Merging #15701 will not alter performance

Comparing 11-13-refactor_ast_linter_semantic_transformer_replace_address_from_ref_with_unstableaddress_unstable_address_ (ceba085) with main (e01c551)1

Summary

✅ 37 untouched

Footnotes

  1. No successful run was found on 11-13-feat_allocator_ast_introduce_unstableaddress_trait (8a61cfd) during the generation of this report, so main (e01c551) was used instead as the comparison base. There might be some changes unrelated to this pull request in this report.

@overlookmotel overlookmotel marked this pull request as ready for review November 14, 2025 14:09
@graphite-app
Copy link
Contributor

graphite-app bot commented Nov 14, 2025

Merge activity

…ref` with `UnstableAddress::unstable_address` (#15701)

Migrate all uses of `Address::from_ptr` and `Address::from_ref` to `UnstableAddress::unstable_address` across whole codebase, except for in `oxc_traverse`, which has particular requirements around aliasing, and can't use `unstable_address`.

This makes no difference to behavior or performance, it's just a more reliable API.
graphite-app bot pushed a commit that referenced this pull request Nov 14, 2025
`Address::from_ptr` is hard to use correctly (as evidenced by rolldown/rolldown#6961).

Introduce a new trait `UnstableAddress` which has a few more guardrails.

### Migration

We should swap all usage of `Address::from_ptr` for `UnstableAddress::unstable_address`.

When `Address::from_ptr` is being used correctly, it can easily be swapped out:

```diff
- let address = Address::from_ptr(node);
+ let address = node.unstable_address();
```

But if `Address::from_ptr` was being used incorrectly, migrating to `unstable_address` will reveal that problem with a compilation error.

`unstable_address` (as the name suggests) does not give the same guarantees about the stability of the `Address` it returns as `GetAddress::address` does. The name of the method makes that explicit.

More details in the doc comment in this PR.

### Migration plan

* #15701 migrates all usage of `Address::from_ptr` and `Address::from_ref` in Oxc's codebase to `unstable_address` (except in `oxc_traverse`, which has particular requirements around aliasing, and can't use `unstable_address`).
* #15702 removes `Address::from_ref`.
* Once this PR lands in an Oxc release, we can migrate Rolldown to `unstable_address`.
* In next Oxc release after that, we'll make `Address::from_ptr` an unsafe method, to discourage its use.
* At a future date, we can migrate `oxc_traverse` to using `NonNull` pointers instead of `*const` pointers, and get rid of `Address::from_ptr` entirely.
@graphite-app graphite-app bot force-pushed the 11-13-feat_allocator_ast_introduce_unstableaddress_trait branch from 29dacc6 to 8a61cfd Compare November 14, 2025 14:59
@graphite-app graphite-app bot force-pushed the 11-13-refactor_ast_linter_semantic_transformer_replace_address_from_ref_with_unstableaddress_unstable_address_ branch from e41fd89 to ceba085 Compare November 14, 2025 15:00
graphite-app bot pushed a commit that referenced this pull request Nov 14, 2025
Remove `Address::from_ref` method.

#15701 removed all usage in Oxc, and this method was only introduced a few weeks ago, so I doubt it's used in Rolldown either.
Base automatically changed from 11-13-feat_allocator_ast_introduce_unstableaddress_trait to main November 14, 2025 15:07
@graphite-app graphite-app bot merged commit ceba085 into main Nov 14, 2025
29 checks passed
@graphite-app graphite-app bot deleted the 11-13-refactor_ast_linter_semantic_transformer_replace_address_from_ref_with_unstableaddress_unstable_address_ branch November 14, 2025 15:08
taearls pushed a commit to taearls/oxc that referenced this pull request Dec 11, 2025
…15700)

`Address::from_ptr` is hard to use correctly (as evidenced by rolldown/rolldown#6961).

Introduce a new trait `UnstableAddress` which has a few more guardrails.

### Migration

We should swap all usage of `Address::from_ptr` for `UnstableAddress::unstable_address`.

When `Address::from_ptr` is being used correctly, it can easily be swapped out:

```diff
- let address = Address::from_ptr(node);
+ let address = node.unstable_address();
```

But if `Address::from_ptr` was being used incorrectly, migrating to `unstable_address` will reveal that problem with a compilation error.

`unstable_address` (as the name suggests) does not give the same guarantees about the stability of the `Address` it returns as `GetAddress::address` does. The name of the method makes that explicit.

More details in the doc comment in this PR.

### Migration plan

* oxc-project#15701 migrates all usage of `Address::from_ptr` and `Address::from_ref` in Oxc's codebase to `unstable_address` (except in `oxc_traverse`, which has particular requirements around aliasing, and can't use `unstable_address`).
* oxc-project#15702 removes `Address::from_ref`.
* Once this PR lands in an Oxc release, we can migrate Rolldown to `unstable_address`.
* In next Oxc release after that, we'll make `Address::from_ptr` an unsafe method, to discourage its use.
* At a future date, we can migrate `oxc_traverse` to using `NonNull` pointers instead of `*const` pointers, and get rid of `Address::from_ptr` entirely.
taearls pushed a commit to taearls/oxc that referenced this pull request Dec 11, 2025
…ref` with `UnstableAddress::unstable_address` (oxc-project#15701)

Migrate all uses of `Address::from_ptr` and `Address::from_ref` to `UnstableAddress::unstable_address` across whole codebase, except for in `oxc_traverse`, which has particular requirements around aliasing, and can't use `unstable_address`.

This makes no difference to behavior or performance, it's just a more reliable API.
taearls pushed a commit to taearls/oxc that referenced this pull request Dec 11, 2025
…15702)

Remove `Address::from_ref` method.

oxc-project#15701 removed all usage in Oxc, and this method was only introduced a few weeks ago, so I doubt it's used in Rolldown either.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-ast Area - AST A-ast-tools Area - AST tools A-linter Area - Linter A-semantic Area - Semantic A-transformer Area - Transformer / Transpiler C-cleanup Category - technical debt or refactoring. Solution not expected to change behavior

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants