Conversation
|
I think we should do this refactoring either way, but if removing the |
|
Unfortunately, removing the But the wrappers are fine. It's actually very convenient to have all of the public definitions in a single file, while having some flexibility for the actual implementations. |
|
Gotcha, that's what I thought, which is why I wasn't worrying too much about messing with the syntax. It definitely is a major downside of using this kind of macro. Eventually it'd be nice to make it a proc macro so that we can use attribute syntax instead. I totally agree about the separation. |
|
Procedural macros are going to make a lot of things way easier and cleaner. Looking forward to them being stabilized some day... |
|
They are stable, or at least enough of them that we could do this. I just didn't have the time to dig in and do it properly when implementing the macro the first time around. |
15e5118 to
fd06a71
Compare
fd06a71 to
71f371c
Compare
71f371c to
fe35b38
Compare
|
I've only made a brief skim through the code here, but it looks good to me as a base to build on! |
|
Thanks a ton for your review, Dan! |
The large
hostcalls.rsfile becomes a module, split in multiple files.The hostcalls implementations themselves are not in the macro any more. What is inside the macro is not valid Rust code, RLS cannot do anything with it, neither can
rustfmt, so maintaining that code was tedious.So, implementations are now outside the macro, with the content of the macro being nothing but thin wrappers.
(draft: not tested on Linux yet)
(update: now compatible with Linux)