async-rs/async-attributes

Experimental language-level polyfills for Async Rust

async-attributes's Issues

bench code

@stjepang I didn't quite do the bench macro the way you said we should do it. Mostly because I forgot what it should be like. Could you maybe share again how it should be? Thanks!

Figure out a way to support checking #[async_attributes::test] in doctests

It would be very valuable for documenting test utils to have cargo check be able to run on #[async_attributes::test] function in doctests.

For example, the obvious errors here would have been caught, as it clearly can't compile: https://github.com/eaze/preroll/blob/c0d15ef0692ef8f933d3501a708f38f0acd69c9a/src/test_utils/mod.rs#L42-L53 (Wrong naming of create_app.)

Unfortunately, `cfg(doctest) seems like it broken and there perhaps is no obvious (or certainly easy) way to fix it, and doesn't seem to be garnering any action: rust-lang/rust#67295

I suggest we find some (even if convoluted) way to run these in doc tests, even if by a manual feature flag.

rls-vscode seem to have issues compiling async-attributes

It appears that projects that depend on async-attributes break rust-lang/rls-vscode#755. I am not exactly how rls-vscode is compiling because I am unable to reproduce issue by running cargo check / cargo build however I do see following error from vscode output:

{"message":"cannot lex `source_file` without source: /Users/gozala/.cargo/registry/src/github.com-1ecc6299db9ec823/quote-1.0.3/src/lib.rs","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":"\u001b[0m\u001b[1m\u001b[38;5;9merror: internal compiler error\u001b[0m\u001b[0m\u001b[1m: cannot lex `source_file` without source: /Users/gozala/.cargo/registry/src/github.com-1ecc6299db9ec823/quote-1.0.3/src/lib.rs\u001b[0m\n\n"}
thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:880:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.44.0-nightly (f509b26a7 2020-03-18) running on x86_64-apple-darwin

note: compiler flags: -C prefer-dynamic -C debuginfo=2 --crate-type proc-macro

note: some of the compiler flags provided by cargo are hidden

{"message":"aborting due to previous error","code":null,"level":"error","spans":[],"children":[],"rendered":"\u001b[0m\u001b[1m\u001b[38;5;9merror\u001b[0m\u001b[0m\u001b[1m: aborting due to previous error\u001b[0m\n\n"}

I am reporting this issue here because it appears that issue is with async-attributes.

I am not seeing same error if I just use quote instead async-attributes so I am not sure what is the problem.

why is there a restriction of `fn main()` on #[async_std::main]?

More of a question really as this was surprising to me.

When using Tokio, you can add #[tokio::main] to any fn and it works as expected, expanding out to eventually calling block_on on a runtime.

I can see https://github.com/async-rs/async-attributes/blob/master/src/lib.rs#L59 and wondered why this restriction is in place? if there's no technical limitation I will happily send a PR 👍

Also whilst here, I noticed that since you expect the attribute to always exist on main, your code doesn't account for visibilty modifiers, eg: pub fn main() would lose the pub

again, if it's just yet to be built then I'd love to help out.

Many thanks for your time.

publish

I don't have access to crates.io yet -- @stjepang could you maybe add me? Thanks!

Request: Support for `x86_64-alpine-linux-musl` target

Compilation for a binary depending on this crate fails when attempting to compile on alpine linux, with the following error message:

error: cannot produce proc-macro for `async-attributes v1.1.1` as the target `x86_64-alpine-linux-musl` does not support these crate types

It'd be awesome for it to support:

• x86_64-alpine-linux-musl
• x86_64-unknown-linux-musl

My use case builds it for alpine in a Docker container:

docker build -f Dockerfile.alpine .

Dockerfile.alpine

FROM alpine:3 AS build

# Install rust
ENV RUSTFLAGS="-C target-feature=+crt-static"
RUN apk update
RUN apk add rust cargo openssl-dev

# Build the application
RUN mkdir -p /src/<PACKAGE_NAME>
COPY . /src/<PACKAGE_NAME>
WORKDIR /src/<PACKAGE_NAME>
RUN cargo build --release

#[bench] attribute dose not work

The current #[bench] attribute is broken because #7 was merged without testing.

code:

#![feature(test)]
extern crate test;

use async_std::task;

#[async_attributes::bench]
async fn bench(b: &mut test::Bencher) {
    b.iter(|| {
        println!("hello world");
    })
}

error:

error: macros that expand to items must be delimited with braces or followed by a semicolon
 --> benches/bench.rs:7:16
  |
7 | async fn bench(b: &mut test::Bencher) {
  |                ^^^^^^^^^^^^^^^^^^^^^
help: change the delimiters to curly braces
  |
7 | async fn bench( {: &mut test::Benche}) {
  |                 ^                   ^
help: add a semicolon
  |
7 | async fn bench(b: &mut test::Bencher;) {
  |                                     ^

error: macro expansion ignores token `,` and any following
 --> benches/bench.rs:7:16
  |
6 | #[async_attributes::bench]
  | -------------------------- caused by the macro expansion here
7 | async fn bench(b: &mut test::Bencher) {
  |                ^^^^^^^^^^^^^^^^^^^^^
  |
  = note: the usage of `async_attributes::bench!` is likely invalid in item context

error: async benchmarks don't take any arguments
 --> benches/bench.rs:7:16
  |
7 | async fn bench(b: &mut test::Bencher) {
  |                ^^^^^^^^^^^^^^^^^^^^^

Backtraces are munged by #[async_attributes::test]

I mentioned this to @yoshuawuyts in a call but figured I should also open an issue here.

Error backtraces are somehow munged when the panic occurs from the handler in this test attribute.
The backtrace will point to e.g. #[async_std::test] rather than the line of the error, and useful location information is usually completely missing from BACKTRACE=short. One has to know how to search through a backtrace to extract error origin location which is not at all ideal for rapid test development.

I don't have an example offhand, as the issue is bad enough that I've changed all my internal test helpers and error propagations to use unwrap().

In fact, we also use this error type on our test cases:

/// A Wrapper around [`Infalliable`](std::convert::Infallible) to force test cases to use `.unwrap()`.
///
/// This is useful because `.unwrap()` provides better stacktraces than propogating errors to [`#[async_std::test]`](async_std::test).
pub type MustUnwrap = Result<(), std::convert::Infallible>;

Edit: it is only now that I realize that this MustUnwrap type is functionally identical to (). 🤦

re-export pin-project macros

https://github.com/taiki-e/pin-project, ref async-rs/async-std#203.

Re-exporting proc macros isn't possible, so we'll have to vendor code with proper attribution and licensing.

Feature idea: support multiple executors

Right now, it looks like this will always execute using async_std::task::block_on. I bet that will work great for most scenarios, and if that's intended to be the full scope of this crate, that makes sense! 😊

My feature idea is: for use cases that demand extremely small code size, fast compile time, deployment on an exotic platform, the ability to use multiple threads, or maybe just to support someone's preference for a certain executor, what do you think of making the executor pluggable? To be up front, I'm interested in using this with spin_on because I have some non-performance intensive code and I'm looking for really fast compile times.

I can think of two variations of this:

1. Explicitly support several useful executors
2. Allow the user to specify their own executor function with a signature similar to fn block_on<F, T>(future: F) -> T where F: Future<Output = T>

I'm pretty sure that this is feasible and I'd be happy to fill in some technical details if this sounds like a desirable feature.