Create Macro to allow async fn main() #104
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- amend temperature example
- create cargo workspace - fix warnings
|
Why did you choose to use a procedural macro rather than implementing lang_items::Termination for |
|
I have no detailled knowledge about the Termination trait but I see two obstacles here:
|
I'm referring to this Line 35 in a8bb4fa |
|
Good point! I added a commit on 103 to implement this and will close this one. |
jrvanwhy
added a commit
to jrvanwhy/libtock-rs
that referenced
this pull request
Dec 12, 2019
…sync main()` function into a normal `main()` function. This is based on PR tock#104.
jrvanwhy
added a commit
to jrvanwhy/libtock-rs
that referenced
this pull request
Dec 12, 2019
…n boards with no LED capsule. This breaks the existing support for `async` `main()` functions. Instead, an `async_main!()` macro is provided to generate a synchronous `main()` that wraps the provided `async` `main()` function (which, unfortunately, must not be called `main()`). This solves tock#111 and tock#113. I would prefer to be more consistent with Tokio and use a procedural macro attribute (as was originally done in tock#104), but I found that has some major drawbacks: 1. If main() does not parse, the error message does not point to the correct code. 2. It adds a requirement to update `syn` every time the toolchain is updated. These drawbacks are elaborated upon in tock#111.
jrvanwhy
added a commit
to jrvanwhy/libtock-rs
that referenced
this pull request
Dec 12, 2019
…n boards with no LED capsule. This breaks the existing support for `async` `main()` functions. Instead, an `async_main!()` macro is provided to generate a synchronous `main()` that wraps the provided `async` `main()` function (which, unfortunately, must not be called `main()`). I would prefer to be more consistent with Tokio and use a procedural macro attribute (as was originally done in tock#104), but I found that has some major drawbacks: 1. If main() does not parse, the error message does not point to the correct code. 2. It adds a requirement to update `syn` every time the toolchain is updated. These drawbacks are elaborated upon in tock#111. This solves tock#111 and tock#113.
|
I re opened this pull request to have a base for discussion. (#115) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
merge after #103
Content of the PR
In this PR we add a proc macro attribute to allow creation of a
async fn main()instead of a synchronousfn main(). The advantage of this macro that the boilerplate code to create an async main function may be subject to breaking changes.Miscellaneous Changes
To simplify usage of the library all crates have been added to a workspace and the CI now also runs tests for the other crates in this repository.
Usage
For an example see the example
async.rs.