reflect
reflect copied to clipboard
dtolnay
Compile-time reflection API for developing robust procedural macros (proof of concept)
I can't find any reason to make the `get_attrs` method only available on `Field` but not `Field`. It's very useful when we try to derive a method without self receiver,...
Simple enough description of the problem. Suppose there was a trait as such: ``` trait MyTrait { fn my_fn(); const MY_CONST: usize; type MyType: TypeBoundsHere; } ``` There is no...
There are cases where type inference is impossible, even when fully qualified paths to every method/function is given. In those cases the macro author need to specify the type. Consider...
Before introducing a thread_local WipFunction in #13, the only way for us to attach literals into the right WipFunction was by constructing them through methods of MakeFunction, as in `f.unit()`...
Suppose we have: ```rust reflect::library! { extern crate demo { trait Demo { fn f(&self); } trait SomeTrait {} fn dynamic_dispatch(&dyn SomeTrait); fn static_dispatch(&T); } } ``` and our user's...
The user shouldn't have to write out their own reflect::library! description of extern crate std. A complete definition of everything in std should be built in to the reflect crate...
As in: ```rust reflect::library! { extern crate std { mod hash { trait Hash { fn hash(&self, state: &mut H) where H: Hasher; } } } } ```
The reflect::library! macro currently only accepts functions as trait functions or associated functions. We'll also need to work with free functions like str::from_utf8 that are not part of a trait...
The current IR (based on WipFunction for functions, and ValueRef + ValueNode for values) just barely works for simple macros but is probably not going to be pleasant to work...