#[derive(OnlyArgs)] fails to recognize type aliases

[z33ky]

#!/usr/bin/env -S cargo +nightly -Z script
```cargo
[dependencies]
onlyargs = "0.1.2"
onlyargs_derive = "0.1.2"
```
type MyInt = i32;

#[derive(onlyargs_derive::OnlyArgs)]
struct MyArgs {
    number: MyInt,
}

fn main() {
    onlyargs::parse::<MyArgs>().unwrap();
}

This results in the following error

error: Expected bool, PathBuf, String, OsString, integer, or float
  --> onlyalias.rs:11:13
   |
11 |     number: MyInt,
   |             ^^^^^

I guess this is a limitation due to using myn.
I'm not sure if it's easy to support/select either myn or syn via cargo-feature.

[parasyte]

I haven't checked other CLI proc-macros, but do any of them support type aliases?

And if so, how? My understanding of proc-macros is that they can only parse a token stream, and an identifier like MyInt doesn't provide any type-level information at all.

To be specific, the derive macro is able to make some decisions based on common type names, like PathBuf because the std type can be imported by name. But it does not (and will never be able to) support renamed PathBuf. For instance use std::path::PathBuf as MyPathBuf and using MyPathBuf as the struct field type will fail with the same error. The macro is not the compiler; it doesn't have any information from the type system.

[z33ky]

Hm true, it only gets the code from the item it's applied to and has no information, or API to get information, about the surrounding code.
It may be possible to forego type matching in the macro and use traits & generics instead, e.g. parse_arg::<#type>() instead of parse_int() etc., though I suppose this comes with worse compile times and perhaps binary size?