add print macros

[yoshuawuyts]

Adds the print macros from async-std here so we can re-export them from submodules. Thanks!

[taiki-e]

@yoshuawuyts Could you add tests? As the document uses async-std's macro, it does not work as this crate's test.

[yoshuawuyts]

@taiki-e I'm not sure how to go about the testing stdout output here. We could do some process spawning + capture, but it doesn't feel great. Do you have any suggestions?

[yoshuawuyts]

Or well, we could check if things compile which may be good enough. I'll add those tests (:

[yoshuawuyts]

I tried adding:

use std::error::Error;

#[test]
fn print_works() {
    futures::executor::block_on(async {
        async_macros::print!("hello {}", "world").await;
        async_macros::println!("hello {}", "world").await;
        async_macros::eprint!("hello {}", "world").await;
        async_macros::eprintln!("hello {}", "world").await;
    });
}

But it fails because write_fmt isn't part of an async-std release yet. I don't think we can add tests right now, and should instead test this within async-std.

[taiki-e]

But it fails because write_fmt isn't part of an async-std release yet. I don't think we can add tests right now, and should instead test this within async-std.

Is it possible to use git dependencies in dev-dependencies? It blocks cargo publish, but for now I'd like to make sure this PR is working.
I'm worried about the possibility of releasing macros like async-rs/async-attributes#9 that don't actually compile.

[taiki-e]

I'm not sure if this PR is good. This will make it difficult to reexport these macros.

[yoshuawuyts]

Maybe my understanding of scoping is off here; but doesn't this include the prelude only within the async block?

The goal of this crate is to provide re-exports for async-std's submodules, because we can't define the macros inside the crate itself. I think as long as we cover that use case we should be okay?

[taiki-e]

I think this is enough for that purpose.

(I was thinking about the restriction that $crate cannot be used. But given proc-macro always has this limitation, we probably don't need to worry.)

[taiki-e]

@taiki-e I'm not sure how to go about the testing stdout output here. We could do some process spawning + capture, but it doesn't feel great. Do you have any suggestions?

Or well, we could check if things compile which may be good enough. I'll add those tests (:

Oh, sorry. I said tests, but in fact I just want to see if it can be compiled.

[taiki-e]

since async-rs/async-std#328 is closed, does this also close?

[yoshuawuyts]

Yeah, I think so!