Allow software tasks to diverge (return -> !) and give them 'static context.

[Ddystopia]

This pull request allows software tasks to return ! and gives Context<'static> to them. In practice this means that polling a task is statically guaranteed to return Poll::Pending. The code will to run until the program's end, thus 'static is justified.

'static is really a superpower and is incredibly useful, as described in the book. Many tasks are not meant to ever end, and 'static can reduce amount of unwanted lifetime annotations, allows better interaction with statics, which allows developers to see usage of the RAM in fine-grained detail and has other great properties.

[datdenkikniet]

I think this is quite a cool feature to have! Sadly I don't have enough know-how to give a useful insight on the soundness of this PR, but I do have one suggestion: as you mention, the book nicely highlights the superpowers you get from a 'static lifetime. It would be great if you could add a section/mention of this new feature in the section you linked to highlight another way of getting this lifetime.

[korken89]

Thank you for the PR!
This makes perfect sense since the introduction of async tasks, where before that it was unsound to have -> !.

I will add it to the weekly meeting agenda so we can discuss this. On the implementation, I'd like you to add at least one test checking this new functionality.

[Ddystopia]

@korken89 Thanks for the review. Can you please point me at the example of such test? I only see compile-fail ui tests, that's probably not what you mean? Because I don't really know how to confirm something with compile-fail test 😅. Maybe you meant something like example or doc test?

[datdenkikniet]

An additional note: to be extra clear, it may be good to mention in the book that you must/should have a .await somewhere in the diverging path to ensure that tasks at the same or other priorities still get to run.

[Ddystopia]

An additional note: to be extra clear, it may be good to mention in the book that you must/should have a .await somewhere in the diverging path to ensure that tasks at the same or other priorities still get to run.

This is already mentioned in the book:

While hardware tasks are assumed to run-to-completion (and return), software tasks may be started (spawned) once and run forever, on the condition that any loop (execution path) is broken by at least one await (yielding operation).

By the way, when we read the documentation, we were confused by this paragraph because it looks like a requirement that rtic enforces at compile time, and we didn't understand how that could work.

[Ddystopia]

@korken89 I added an example, as we discussed yesterday.

[korken89]

Great work, thank you!