sdk: Extract slot-history sysvar #3249
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
joncinque
commented
Oct 21, 2024
sdk/slot-history/src/lib.rs
Outdated
Comment on lines
5
to
7
| //! The sysvar ID is declared in [`sysvar`]. | ||
| //! | ||
| //! [`sysvar`]: crate::sysvar |
There was a problem hiding this comment.
This will get done in future work, once all the sysvar types are extracted
#### Problem Just about all of the sysvars exist in separate crates, except for slot history. #### Summary of changes Extract it into a new crate. Looks pretty similar to slot hashes, except all of the `info!` calls were removed in the tests.
joncinque
force-pushed
the
extract-slot-history
branch
from
7c61908 to
99035a3
Compare
kevinheavey
reviewed
Oct 22, 2024
sdk/slot-history/src/lib.rs
Outdated
| //! | ||
| //! The sysvar ID is declared in [`sysvar::slot_history`]. | ||
| //! | ||
| //! [`sysvar`]: https://docs.rs/solana-program/latest/solana_program/sysvar/slot_history |
There was a problem hiding this comment.
this should be [`sysvar::slot_history`]
kevinheavey
approved these changes
Oct 22, 2024
febo
reviewed
Oct 22, 2024
| assert_eq!(slot_history.oldest(), 1); | ||
| } | ||
| } | ||
| pub use {solana_clock::Slot, solana_slot_history::*}; |
There was a problem hiding this comment.
Should we add the deprecated message on this re-export?
|
Looks good - I think we are only missing the crate owner for CI. |
|
@yihau can you accept the ownership of |
|
✅ |
|
@febo can I get an approval to merge this? |
febo
approved these changes
Oct 28, 2024
joncinque
added a commit
that referenced
this pull request
Oct 29, 2024
* sdk: Extract `solana-sysvar` crate #### Problem The sysvars in `solana-program` are tightly coupled with types that exist in `solana-program`. For example, all of the special sysvar getters like `Rent::get()` are implemented through a macro that falls back to using `program_stubs`. Because of this tight coupling, it's difficult to pull out bits for the sysvars. #### Summary of changes After numerous attempts, I've decided to keep it simple and only extract `SysvarId`, its helper macros, and `get_sysvar`. To go along with that, all of the separated sysvar crates now implement the sysvar ids themselves under a new `sysvar` feature. This new feature might be overkill, so let me know if we should just include the sysvar ids by default. I went with a feature to include an implementation using the `sol_get_sysvar` syscall in the future. It was really messy to include the `Sysvar` trait from `solana-program` because it falls back to using `bincode`, which we know performs poorly for on-chain programs. So the future idea is to create a new `Sysvar` trait in `solana-sysvar` which will require fewer bits to deserialize sysvars. Let me know what you think about this PR and the future idea! Note that I'll need to rebase this on top of #3249 and #3272 when they land. * Add solana-define-syscall for solana builds * Rename solana-sysvar -> solana-sysvar-id * Move back `get_sysvar` to solana-program * Update lockfile for v2.2
mergify bot
pushed a commit
that referenced
this pull request
Oct 29, 2024
* sdk: Extract `solana-sysvar` crate #### Problem The sysvars in `solana-program` are tightly coupled with types that exist in `solana-program`. For example, all of the special sysvar getters like `Rent::get()` are implemented through a macro that falls back to using `program_stubs`. Because of this tight coupling, it's difficult to pull out bits for the sysvars. #### Summary of changes After numerous attempts, I've decided to keep it simple and only extract `SysvarId`, its helper macros, and `get_sysvar`. To go along with that, all of the separated sysvar crates now implement the sysvar ids themselves under a new `sysvar` feature. This new feature might be overkill, so let me know if we should just include the sysvar ids by default. I went with a feature to include an implementation using the `sol_get_sysvar` syscall in the future. It was really messy to include the `Sysvar` trait from `solana-program` because it falls back to using `bincode`, which we know performs poorly for on-chain programs. So the future idea is to create a new `Sysvar` trait in `solana-sysvar` which will require fewer bits to deserialize sysvars. Let me know what you think about this PR and the future idea! Note that I'll need to rebase this on top of #3249 and #3272 when they land. * Add solana-define-syscall for solana builds * Rename solana-sysvar -> solana-sysvar-id * Move back `get_sysvar` to solana-program * Update lockfile for v2.2 (cherry picked from commit 838c195) # Conflicts: # Cargo.toml
joncinque
added a commit
that referenced
this pull request
Oct 30, 2024
* sdk: Extract `solana-sysvar` crate #### Problem The sysvars in `solana-program` are tightly coupled with types that exist in `solana-program`. For example, all of the special sysvar getters like `Rent::get()` are implemented through a macro that falls back to using `program_stubs`. Because of this tight coupling, it's difficult to pull out bits for the sysvars. #### Summary of changes After numerous attempts, I've decided to keep it simple and only extract `SysvarId`, its helper macros, and `get_sysvar`. To go along with that, all of the separated sysvar crates now implement the sysvar ids themselves under a new `sysvar` feature. This new feature might be overkill, so let me know if we should just include the sysvar ids by default. I went with a feature to include an implementation using the `sol_get_sysvar` syscall in the future. It was really messy to include the `Sysvar` trait from `solana-program` because it falls back to using `bincode`, which we know performs poorly for on-chain programs. So the future idea is to create a new `Sysvar` trait in `solana-sysvar` which will require fewer bits to deserialize sysvars. Let me know what you think about this PR and the future idea! Note that I'll need to rebase this on top of #3249 and #3272 when they land. * Add solana-define-syscall for solana builds * Rename solana-sysvar -> solana-sysvar-id * Move back `get_sysvar` to solana-program * Update lockfile for v2.2 (cherry picked from commit 838c195) # Conflicts: # Cargo.toml
joncinque
added a commit
that referenced
this pull request
Oct 30, 2024
sdk: Extract `solana-sysvar-id` crate (#3309) * sdk: Extract `solana-sysvar` crate #### Problem The sysvars in `solana-program` are tightly coupled with types that exist in `solana-program`. For example, all of the special sysvar getters like `Rent::get()` are implemented through a macro that falls back to using `program_stubs`. Because of this tight coupling, it's difficult to pull out bits for the sysvars. #### Summary of changes After numerous attempts, I've decided to keep it simple and only extract `SysvarId`, its helper macros, and `get_sysvar`. To go along with that, all of the separated sysvar crates now implement the sysvar ids themselves under a new `sysvar` feature. This new feature might be overkill, so let me know if we should just include the sysvar ids by default. I went with a feature to include an implementation using the `sol_get_sysvar` syscall in the future. It was really messy to include the `Sysvar` trait from `solana-program` because it falls back to using `bincode`, which we know performs poorly for on-chain programs. So the future idea is to create a new `Sysvar` trait in `solana-sysvar` which will require fewer bits to deserialize sysvars. Let me know what you think about this PR and the future idea! Note that I'll need to rebase this on top of #3249 and #3272 when they land. * Add solana-define-syscall for solana builds * Rename solana-sysvar -> solana-sysvar-id * Move back `get_sysvar` to solana-program * Update lockfile for v2.2 (cherry picked from commit 838c195) # Conflicts: # Cargo.toml Co-authored-by: Jon C <me@jonc.dev>
ray-kast
pushed a commit
to abklabs/agave
that referenced
this pull request
Nov 27, 2024
* sdk: Extract slot-history sysvar #### Problem Just about all of the sysvars exist in separate crates, except for slot history. #### Summary of changes Extract it into a new crate. Looks pretty similar to slot hashes, except all of the `info!` calls were removed in the tests. * Remove clock dependency * Update doc link * Fix rebase errors * Update doc link (again) * Add deprecation warning
ray-kast
pushed a commit
to abklabs/agave
that referenced
this pull request
Nov 27, 2024
* sdk: Extract `solana-sysvar` crate #### Problem The sysvars in `solana-program` are tightly coupled with types that exist in `solana-program`. For example, all of the special sysvar getters like `Rent::get()` are implemented through a macro that falls back to using `program_stubs`. Because of this tight coupling, it's difficult to pull out bits for the sysvars. #### Summary of changes After numerous attempts, I've decided to keep it simple and only extract `SysvarId`, its helper macros, and `get_sysvar`. To go along with that, all of the separated sysvar crates now implement the sysvar ids themselves under a new `sysvar` feature. This new feature might be overkill, so let me know if we should just include the sysvar ids by default. I went with a feature to include an implementation using the `sol_get_sysvar` syscall in the future. It was really messy to include the `Sysvar` trait from `solana-program` because it falls back to using `bincode`, which we know performs poorly for on-chain programs. So the future idea is to create a new `Sysvar` trait in `solana-sysvar` which will require fewer bits to deserialize sysvars. Let me know what you think about this PR and the future idea! Note that I'll need to rebase this on top of anza-xyz#3249 and anza-xyz#3272 when they land. * Add solana-define-syscall for solana builds * Rename solana-sysvar -> solana-sysvar-id * Move back `get_sysvar` to solana-program * Update lockfile for v2.2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Just about all of the sysvars exist in separate crates, except for slot history.
Summary of changes
Extract it into a new crate. Looks pretty similar to slot hashes. All of the
info!calls and logging dependencies were removed.