sdk: Extract last-restart-slot crate #3272
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
#### Problem Just about all of the sysvars have been extract in some way from solana-program, but the last restart slot sysvar has not. #### Summary of changes Following most of the other crates that have done this, move it out.
kevinheavey
reviewed
Oct 22, 2024
| @@ -493,7 +493,6 @@ pub mod incinerator; | |||
| pub mod instruction; | |||
| pub mod keccak; | |||
| pub mod lamports; | |||
| pub mod last_restart_slot; | |||
There was a problem hiding this comment.
looks like last_restart_slot.rs still needs to be deleted
There was a problem hiding this comment.
Ah right, thanks for noticing!
|
Looks good – there is only the nit that @kevinheavey mentioned. |
|
@yihau can you accept 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 last-restart-slot crate #### Problem Just about all of the sysvars have been extract in some way from solana-program, but the last restart slot sysvar has not. #### Summary of changes Following most of the other crates that have done this, move it out. * Remove last_restart_slot.rs
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 have been extract in some way from solana-program, but the last restart slot sysvar has not.
Summary of changes
Following most of the other crates that have done this, move it out.