actor API syntax

[japaric]

see rtic-rs/rfcs#52 for details
includes: core proposal and first #[init] extension

Co-authored-by: Jonas Schievink jonasschievink@gmail.com

[perlindgren]

@japaric

I've looked at the syntax PR. In src/parse/app.rs line 396, I don't quite follow

                                let ident = field.ident.as_ref().expect("UNREACHABLE");

Can this expect be triggered, if so how, and what would the implication be (what happens if the identifier is set to "UNREACHABLE")?

As I understand the extension of the syntax allow init to optionally return an actors struct, and current projects should still work as before.

Is there a mechanism checking if an Actor struct has been declared but not used returned by init?

/Per

[perlindgren]

Another thing that would be good is some more tests (if I'm not mistaken there is just one test assumed to pass, no fail tests).

[japaric]

@perlindgren the .expect method is like Option::unwrap but includes a panic message. you can think of .expect("message") it as short-hand for .unwrap_or_else(|| panic!("message"))`.

Can this expect be triggered, if so how

that panicking branch cannot be hit due to guarantees in the syn crate. when you have a FieldsNamed value, it's guaranteed that Field.ident will be the Some variant. FieldsNamed corresponds to the { a: i32 } syntax of a braced struct item (struct X { a: i32 }); whereas FieldsUnnamed is used for tuple structs like struct NewType(i32).

if you see a few lines above you'll see that the code is handling the Named (struct fields) case.

rtic-syntax/src/parse/app.rs

Lines 394 to 396 in e19feea

	if let Fields::Named(fields) = &mut struct_item.fields {
	for field in &mut fields.named {
	let ident = field.ident.as_ref().expect("UNREACHABLE");

what happens if the identifier is set to "UNREACHABLE"

the syn parser has no special handling for that particular identifier so it's not handled differently here than if a different identifier was used.

Is there a mechanism checking if an Actor struct has been declared but not used returned by init?

yes, there's a parser check for that. if an #[actors] struct is defined and the tuple is missing an element then you get this error

rtic-syntax/src/parse/app.rs

Lines 574 to 582 in e19feea

	(Some(actors_ident), None) => {
	return Err(parse::Error::new(
	actors_ident.span(),
	format!(
	"`#[init]` return type needs to include `{}` as the 4th tuple element ",
	actors_ident
	),
	));
	}

Another thing that would be good is some more tests (if I'm not mistaken there is just one test assumed to pass, no fail tests).

indeed, there are "success path" tests but no "failure path" tests in this PR. it would be possible to test the failure condition about init return type missing a tuple element in this repo

[perlindgren]

As discussed on the Matrix, the current consensus is a "forked release", under the same rtic-rs github. Let's discuss further on next/upcoming weekly meeting.