[wip] #[derive(Ereport)] for serialization with known max lengths

[hawkw]

No description provided.

[github-actions]

license-eye has totally checked 603 files.

Valid	Invalid	Ignored	Fixed
602	1	0	0

Click to see the invalid file list

• lib/ereport/examples/test-expanded.rs

[github-actions]

Suggested change

	#![feature(prelude_import)]
	// This Source Code Form is subject to the terms of the Mozilla Public
	// License, v. 2.0. If a copy of the MPL was not distributed with this
	// file, You can obtain one at https://mozilla.org/MPL/2.0/.
	#![feature(prelude_import)]

[hawkw]

Okay, so the current approach as of e2e5106 seems to be more or less functional. But, there's one big flaw: it turns out there isn't really a way to take something like the current trait:

hubris/lib/ereport/src/lib.rs

Lines 12 to 18 in 13de2cf

	pub trait EreportData: Encode<()> {
	/// The maximum length of the CBOR-encoded representation of this value.
	///
	/// The value is free to encode fewer than this many bytes, but may not
	/// encode more.
	const MAX_CBOR_LEN: usize;
	}

and write a function like

pub fn encode_ereport<'buf, E: EreportData>(
    ereport: &E,
    buf: &'buf mut [u8; E::MAX_CBOR_LEN],
) -> &'buf [u8] {
    let mut encoder = Encoder::new(buf);
    todo!()
}

because this runs afoul of

error: generic parameters may not be used in const operations
  --> lib/ereport/src/lib.rs:22:25
   |
22 |     buf: &'buf mut [u8; E::MAX_CBOR_LEN],
   |                         ^^^^^^^^^^^^^^^ cannot perform const operation using `E`
   |
   = note: type parameters may not be used in const expressions
   = help: add `#![feature(generic_const_exprs)]` to allow generic const expressions

This feels pretty unfortunate, as a function like this is basically the UX I was hoping to be able to have. Currently, the user can get the type to tell it what the right length for the buffer is, and use it to construct a buffer, but we can't easily have an API that ensures you use the correct-length buffer when encoding, which is too bad.

We could just enable the nightly-only #![feature(generic_const_exprs)] and have it work, but I think we're trying to avoid adding new nightly features.

Another option I'm thinking about is changing the trait to something like:

pub trait EreportData: Encode<()> {
    /// The maximum length of the CBOR-encoded representation of this value.
    ///
    /// The value is free to encode fewer than this many bytes, but may not
    /// encode more.
    const MAX_CBOR_LEN: usize;
    type NeededBuf: AsRef<[u8]> + AsMut<[u8]>;
}

and having the derive macro generate a NeededBuf associated type that's [u8; MAX_CBOR_LEN]. We could then have an encode function that's like

pub fn encode_ereport<'buf, E: EreportData>(
    ereport: &E,
    buf: &'buf mut E::NeededBuf,
) -> &'buf [u8] {
   // ...
}

and you wouldn't be able to call it with a too-short array. But, this might be overthinking it...

[hawkw]

Update: nope, the approach proposed in #2246 (comment) still ends up using a generic parameter in a const expression if the type is generic over another type implementing EreportData. So, we really just can't quite do that without #![feature(generic_const_exprs)]. I think the current state of this is still useful as it at least gives us a way to "manually" construct a correct-length buffer. You can choose to misuse the derived implementation with a wrong-length buffer, but...you could do this before, too. It would be nice to have a misuse-resistant API, but I can accept just having an API that does the Right Thing if you don't misuse it!