actor API syntax

[japaric]

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

Co-authored-by: Jonas Schievink [email protected]

[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.

https://github.com/rtic-rs/rtic-syntax/blob/e19feea0b834055f24a2c2242016ac7020848e6d/src/parse/app.rs#L394-L396

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

https://github.com/rtic-rs/rtic-syntax/blob/e19feea0b834055f24a2c2242016ac7020848e6d/src/parse/app.rs#L574-L582

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.