David Tolnay
David Tolnay
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...
This part of the current generated code would be better expressed as a `match`, which would be able to work equally well against enums later. ```rust let __v3 = &__v0.x;...
The generated code should be more aggressive about avoiding redundancy and reusing Value nodes that have been previously instantiated.
Many of the `reflect::Value` objects instantiated may never be passed to a library call and do not need to be emitted in the generated code.
If a library method is declared to take self by reference or mut reference and the user's macro invokes the method with a receiver that is not a reference, it...
The `Enum::match_variant` method currently panics with `unimplemented!()`. It needs to emit a `match` expression with one arm for each enum variant in the receiver.
Part of the Debug example currently compiles to: ```rust let __v7 = "x"; let _ = ::std::fmt::DebugStruct::field(__v6, __v7, __v3); ``` It doesn't matter here for correctness but this would be...
As observed in https://github.com/dtolnay/ryu/pull/34#issue-496690273, the 32-bit and 64-bit float-to-string benchmark in this repo is something like 40% faster than the exact same benchmark in https://github.com/ulfjack/ryu. We need to examine whether...
For example by passing into the closure a Deserializer from which you can read the value.