meena@76ix ~/s/a/webfinger (feat/async-trait)> cargo +nightly build --features async
Compiling webfinger v0.5.0 (/home/meena/src/ap/webfinger)
error[E0632]: cannot provide explicit generic arguments when `impl Trait` is used in argument position
--> src/async_trait.rs:8:1
|
8 | #[async_trait]
| ^^^^^^^^^^^^^^ explicit generic argument not allowed
|
= note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info)
error: aborting due to previous error
error: could not compile `webfinger`.
To learn more, run the command again with --verbose.
meena@76ix ~/s/a/webfinger (feat/async-trait) [101]>
current status:
```
meena@76ix ~/s/a/webfinger (feat/async-trait)> cargo +nightly build --features async
Compiling webfinger v0.5.0 (/home/meena/src/ap/webfinger)
error[E0632]: cannot provide explicit generic arguments when `impl Trait` is used in argument position
--> src/async_trait.rs:8:1
|
8 | #[async_trait]
| ^^^^^^^^^^^^^^ explicit generic argument not allowed
|
= note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info)
error: aborting due to previous error
error: could not compile `webfinger`.
To learn more, run the command again with --verbose.
meena@76ix ~/s/a/webfinger (feat/async-trait) [101]>
```
back to building, now we need to add a test for async.
This: https://gist.github.com/a5727727c2f55be6f37e937bfc232d32 is not it: https://gist.github.com/ae41ec328a2a443fa02214a4b0f19281
I feel like test_my_resolver/test_my_async_resolver are more coverage oriented than correctness : the valid answer is barely validated, however this is unrelated to this pr
I’m not sure this requires to be async, I would expect an implementation to return one of its fields, but I guess there is nothing wrong with too much async, it’ll just get optimized away during monomorphisation
I'm not sure this requires to be async, I would expect an implementation to return one of its fields, but I guess there is nothing wrong with too much async, it'll just get optimized away during monomorphisation
igalic(Migrated from github.com)
reviewed 11 months ago
I feel like test_my_resolver/test_my_async_resolver are more coverage oriented than correctness : the valid answer is barely validated, however this is unrelated to this pr
how do you suggest improving those?
ideally, i’d like to do that before a next release, because, more importantly, i’d like to call the next release ‘1.0’
> LGTM
>
> I feel like test_my_resolver/test_my_async_resolver are more coverage oriented than correctness : the valid answer is barely validated, however this is unrelated to this pr
how do you suggest improving those?
ideally, i'd like to do that before a next release, because, more importantly, i'd like to call the next release '1.0'
add a feature (behind a off-by-default flag) to use async trait implementations.
for now, this doesn’t work, because
impl String
is not (necessarily)Send
safe.current status:
Codecov Report
86.45% <81.25%> (-1.43%)
97.54% <98.50%> (+3.42%)
100.00% <100.00%> (ø)
100.00% <100.00%> (ø)
Continue to review full report at Codecov.
back to building, now we need to add a test for async.
This: https://gist.github.com/a5727727c2f55be6f37e937bfc232d32 is not it: https://gist.github.com/ae41ec328a2a443fa02214a4b0f19281
LGTM
I feel like test_my_resolver/test_my_async_resolver are more coverage oriented than correctness : the valid answer is barely validated, however this is unrelated to this pr
I’m not sure this requires to be async, I would expect an implementation to return one of its fields, but I guess there is nothing wrong with too much async, it’ll just get optimized away during monomorphisation
and if it’s
async
in the trait signature, it means you can useawait
in the function body.how do you suggest improving those?
ideally, i’d like to do that before a next release, because, more importantly, i’d like to call the next release ‘1.0’
hum, endpoint() rely way more on find() than I though so in fact any incorrectness on a valid answer would come from find(), never mind my comment
Reviewers
4e8f12810c
.