Implement inline generics

[escritorio-gustavo]

Implementation of inlined generics. Not 100% sure it works, but it did pass the #[ignore]d test

Fixes #56

[escritorio-gustavo]

This may have a flaw for the case where generics have both a trait bound and a default type, in which case it will keep the previous behavior. Not sure how to avoid this though

[NyxCode]

Besides maybe adding a small comment why there's this "null" literal (to make exporting generic types with T::<()>::decl() work, right?), this looks great!
Otherwise, this looks great, thanks!

[escritorio-gustavo]

to make exporting generic types with T::<()>::decl() work, right?

Yes, when exporting the struct itself, () is used as the default type, which turns into "null". When you give it a type argument in a struct field, it uses the type's .name()

[escritorio-gustavo]

This may have a flaw for the case where generics have both a trait bound and a default type

The reason for this is a test that has something along the lines of Struct<T: ToString>. In this case, the default type is not (), it is &'static str. I don't know how the default type is decided in this case, so I wasn't able to implement that, and even if I did, if someone were to use the default type (or any type where .name() has the same result) this implementation would just give them T (or whatever the name of the type param is)

[NyxCode]

This may have a flaw for the case where generics have both a trait bound and a default type

The reason for this is a test that has something along the lines of Struct<T: ToString>. In this case, the default type is not (), it is &'static str. I don't know how the default type is decided in this case, so I wasn't able to implement that, and even if I did, if someone were to use the default type (or any type where .name() has the same result) this implementation would just give them T (or whatever the name of the type param is)

I think that's fine for now, this PR is still an improvement on the status quo. Maybe we should create an issue for this, together with an ignored test case, so that we dont forget about this?

[escritorio-gustavo]

That might be the best way to go. Btw, I tried an aproach using std::any::Any and std::any::TypeId. That seems like the best way to check if two Rust types are equal, but I ran into lifetime problems (T is required to be 'static) so I went for this approach. Maybe that will be useful in the future?

[escritorio-gustavo]

This may have a flaw for the case where generics have both a trait bound and a default type, in which case it will keep the previous behavior. Not sure how to avoid this though

This actually happens in case either a default type or a trait bound exist, it's not necessary to have both at the same time

[escritorio-gustavo]

The best way to solve this permanently would be a way to identify whether we are expanding a flatten/inline or an export.
flatten and inline should always emit T::name()
export should always emit T