docs(lee,lez): trim PR 740's doc comments, fix stale loader_core crate name

ProgramData::segment_count's doc referenced the pre-rename `loader_core`
path; fix to `program_loader_core`. Tighten execute_deploy's and
MAX_SEGMENT_DATA_LEN's doc comments and one test's rationale comment.
This commit is contained in:
Marvin Jones
2026-08-23 08:08:30 -04:00
parent 1ac6335e29
commit a01cebe813
3 changed files with 9 additions and 16 deletions
+2 -3
View File
@@ -65,9 +65,8 @@ pub type ProgramId = [u32; 8];
#[derive(Debug, PartialEq, Eq, BorshSerialize, BorshDeserialize)]
pub struct ProgramData {
pub image_id: ProgramId,
/// How many bytecode segment accounts follow, so a reader knows exactly how many
/// `loader_core::deploy_segment_account_id(image_id, 0..segment_count, update_auth)`
/// accounts to fetch without probing.
/// How many bytecode segment accounts follow, so a reader knows how many to fetch without
/// probing (see `program_loader_core::deploy_segment_account_id`).
pub segment_count: u32,
pub update_auth: AccountId,
}
+2 -4
View File
@@ -68,10 +68,8 @@ fn get_program_returns_none_for_a_missing_segment() {
assert_eq!(result, None);
}
/// If a segment's bytes are corrupted (or the header's `segment_count` is wrong in a way that
/// still finds real segment accounts, just not the right ones), the reconstructed elf's real
/// `image_id` won't match what the header claims — `get_program` must reject that distinguishably
/// from plain absence, matching "sequencer returns an error about a bad program elf."
/// A corrupted segment's reconstructed `image_id` won't match the header's claim —
/// `get_program` must reject that distinguishably from plain absence.
#[test]
fn get_program_rejects_a_corrupted_segment() {
let program = crate::test_methods::claimer();
+5 -9
View File
@@ -22,10 +22,8 @@ const KERNEL_ELF: &[u8] = include_bytes!("kernel.bin");
/// Max bytes of `user_elf` one segment account's `Data` may hold.
///
/// Chosen comfortably under `lee_core::account::data::DATA_MAX_LENGTH` (100 KiB), leaving
/// headroom for any future per-segment framing without needing to touch this constant, while
/// still yielding a sane segment count (4-6) for every real production ELF (340-490 KB
/// `user_elf`).
/// Comfortably under `DATA_MAX_LENGTH` (100 KiB), with headroom for future per-segment framing;
/// yields 4-6 segments for a typical 340-490 KB `user_elf`.
pub const MAX_SEGMENT_DATA_LEN: usize = 96 * 1024;
#[derive(Serialize, Deserialize)]
@@ -259,11 +257,9 @@ pub fn immutable_deploy_account_id(image_id: ProgramId) -> AccountId {
/// Executes the `Deploy` instruction.
///
/// Verifies `user_elf` decodes as a valid RISC0 program (combined with the assumed
/// [`KERNEL_ELF`]), derives its header and segment PDAs (chunking `user_elf` across as many
/// segments as [`plan_deploy`] reports), and claims all of them.
///
/// Called natively from dispatch's `RESERVED_DEPLOYMENT_PROGRAM_ACCOUNT_ID` shortcut (see that
/// Verifies `user_elf` decodes as a valid RISC0 program (with the assumed [`KERNEL_ELF`]),
/// derives its header and segment PDAs via [`plan_deploy`], and claims all of them. Called
/// natively from dispatch's `RESERVED_DEPLOYMENT_PROGRAM_ACCOUNT_ID` shortcut (see that
/// constant's doc comment in `lee_core::program`) — `Deploy` has no guest binary of its own.
#[must_use]
pub fn execute_deploy(