Skip to content

Comments

refactor(data_structures): add PhantomData field to Stack and NonEmptyStack#15794

Merged
graphite-app[bot] merged 1 commit intomainfrom
11-17-refactor_data_structures_add_phantomdata_field_to_stack_and_nonemptystack_
Nov 17, 2025
Merged

refactor(data_structures): add PhantomData field to Stack and NonEmptyStack#15794
graphite-app[bot] merged 1 commit intomainfrom
11-17-refactor_data_structures_add_phantomdata_field_to_stack_and_nonemptystack_

Conversation

@overlookmotel
Copy link
Member

@overlookmotel overlookmotel commented Nov 17, 2025

Data structures which own Ts should contain a PhantomData<T> field to signal to compiler the ownership semantics. For example std::vec::Vec does this.

Add PhantomData field to Stack and NonEmptyStack.

It's unclear to me if this is actually required for soundness or not. In the case of std::vec::Vec, it definitely is, but Vec uses #[may_dangle] in its Drop impl. Ideally we would use #[may_dangle] in these Stack types too, to loosen the borrow-checker's restrictions, but we're not able to as it's not available in stable Rust.

Given that we're not using #[may_dangle], maybe PhantomData is not required either, but it costs nothing, so it's better to be on safe side and add it.

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

overlookmotel commented Nov 17, 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.

@codspeed-hq
Copy link

codspeed-hq bot commented Nov 17, 2025

CodSpeed Performance Report

Merging #15794 will not alter performance

Comparing 11-17-refactor_data_structures_add_phantomdata_field_to_stack_and_nonemptystack_ (4505499) with 11-17-docs_data_structures_doc_comments_on_fields_of_stack_ (aabac4a)

Summary

✅ 37 untouched

@overlookmotel overlookmotel marked this pull request as ready for review November 17, 2025 14:50
@overlookmotel overlookmotel self-assigned this Nov 17, 2025
@overlookmotel overlookmotel force-pushed the 11-17-refactor_data_structures_add_phantomdata_field_to_stack_and_nonemptystack_ branch from 9db06aa to 4505499 Compare November 17, 2025 14:53
@overlookmotel overlookmotel force-pushed the 11-17-docs_data_structures_doc_comments_on_fields_of_stack_ branch from e50da92 to aabac4a Compare November 17, 2025 14:53
@overlookmotel overlookmotel added the 0-merge Merge with Graphite Merge Queue label Nov 17, 2025
Copy link
Member Author

overlookmotel commented Nov 17, 2025

Merge activity

…nEmptyStack` (#15794)

Data structures which own `T`s should contain a `PhantomData<T>` field to signal to compiler the ownership semantics. For example `std::vec::Vec` does this.

Add `PhantomData` field to `Stack` and `NonEmptyStack`.

It's unclear to me if this is actually required for soundness or not. In the case of `std::vec::Vec`, it definitely is, but `Vec` uses `#[may_dangle]` in its `Drop` impl. Ideally we would use `#[may_dangle]` in these `Stack` types too, to loosen the borrow-checker's restrictions, but we're not able to as it's not available in stable Rust.

Given that we're not using `#[may_dangle]`, maybe `PhantomData` is not required either, but it costs nothing, so it's better to be on safe side and add it.
@graphite-app graphite-app bot force-pushed the 11-17-docs_data_structures_doc_comments_on_fields_of_stack_ branch from aabac4a to c81a331 Compare November 17, 2025 16:02
@graphite-app graphite-app bot force-pushed the 11-17-refactor_data_structures_add_phantomdata_field_to_stack_and_nonemptystack_ branch from 4505499 to 32f4fdd Compare November 17, 2025 16:03
Base automatically changed from 11-17-docs_data_structures_doc_comments_on_fields_of_stack_ to main November 17, 2025 16:08
@graphite-app graphite-app bot merged commit 32f4fdd into main Nov 17, 2025
22 checks passed
@graphite-app graphite-app bot deleted the 11-17-refactor_data_structures_add_phantomdata_field_to_stack_and_nonemptystack_ branch November 17, 2025 16:09
@graphite-app graphite-app bot removed the 0-merge Merge with Graphite Merge Queue label Nov 17, 2025
taearls pushed a commit to taearls/oxc that referenced this pull request Dec 11, 2025
…nEmptyStack` (oxc-project#15794)

Data structures which own `T`s should contain a `PhantomData<T>` field to signal to compiler the ownership semantics. For example `std::vec::Vec` does this.

Add `PhantomData` field to `Stack` and `NonEmptyStack`.

It's unclear to me if this is actually required for soundness or not. In the case of `std::vec::Vec`, it definitely is, but `Vec` uses `#[may_dangle]` in its `Drop` impl. Ideally we would use `#[may_dangle]` in these `Stack` types too, to loosen the borrow-checker's restrictions, but we're not able to as it's not available in stable Rust.

Given that we're not using `#[may_dangle]`, maybe `PhantomData` is not required either, but it costs nothing, so it's better to be on safe side and add it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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.

1 participant