Use on stable Rust?

[askeksa]

Is there a plan to make the crate work on stable Rust at some point, i.e. using procedural macros (either via https://github.com/dtolnay/proc-macro-hack or using proper expression macros when they eventually arrive)?

I would like to use dynasm-rs for a JIT for modular sound synthesis, and I don't mind depending on unstable Rust to begin with, but it would be nice to have some assurance that it will work on stable eventually.

[CensoredUsername]

Currently the plan is to wait for proper expression macros when they eventually arrive. There is currently no other solution that still allows dynasm to generate proper errors for invalid assembly, which I consider quite critical to a proper user experience. When expression macros eventually arrive on stable I'll gladly get it working on there.

[askeksa]

Good to hear there is a plan. This crate and its requirements is probably good input to the design discussions for expression macros. Looking forward to playing more with this. :) 👍

[RReverser]

FWIW proc macros can be defined on stable Rust 1.29 now and it will be possible to use them on stable 1.30 (which is going to be released soon) so it might be worth to start migrating code over to new APIs.

[CensoredUsername]

Yay, thanks for the headsup.

[CensoredUsername]

I've ported the entire project to proc-macro on the dev branch and will be continuing development there. We'll have to be on nightly for a while still though since proc_macro_diagnostic and proc_macro_hygiene are not stabilized yet (the former necessary to give decent error messages, the latter to actually expand to expressions. However, I can now continue development of new architectures without worrying about having to redo their implementation, so work on the dev branch will continue for a while.

[dtolnay]

proc_macro_diagnostic

It looks like the only code using proc_macro_diagnostic is ::err. That would be better implemented by rendering errors as compile_error invocations in the output token stream, spanned with whatever span you want the error to appear on. This is similar to Syn's Error::to_compile_error.

proc_macro_hygiene

https://github.com/dtolnay/proc-macro-hack should entirely eliminate the need for this feature.

[CensoredUsername]

This is similar to Syn's Error::to_compile_error.

I didn't know about this approach, but it should be doable to implement without significant changes. Thanks!

https://github.com/dtolnay/proc-macro-hack

Interesting. I'm having trouble understanding how it works but it looks promising.

Outside of those I still need to find a solution for crate or file scoping of alias declarations, but it solves the largest issues I had to moving to stable. Thanks!

[dtolnay]

How are alias declarations currently done that is not stable?

[CensoredUsername]

In the old plugin system, alias declarations were scoped crate-local. This was done in a very hackish way (querying rustc which crate we were expanding in, and having a global static mapping of crate name to alias / current arch definition).

Using proc-macro we don't have access to this information. I was thinking of changing alias definitions to be file-local (using information from Span::call_site()'s file name), but these methods were currently listed as semver-exempt. Note that this is currently not implemented yet, causing alias declarations to possibly be global which is something I'd like to avoid.

[CensoredUsername]

Hurray! We're now using proc-macro (with a few nightly features still required).

[MarkMcCaskey]

Hello! I'd also like if dynasm-rs worked on stable. Have things changed much over the last year? I may be able to work on this in my free time if there's a path forward!

[CensoredUsername]

@MarkMcCaskey It's currently still a nightly-only lib. This is due to two reasons. The first is the use of Span information in the proc macro to emit accurate errors and handle file local data. The second is that proc macros expanding in statement or expression position is still unstable and requires the proc_macro_hygiene feature. Any help on getting that feature stabilized in rustc is greatly appreciated!

[frol]

I am looking into resolving this. It seems that there are two unstable features in use:

• proc_macro_diagnostic

  It seems that this is used for better compilation time error messages, which can be feature-gated for stable Rust with some degradation of the developer experience.

• proc_macro_span

  It seems that it is used to handle file local data. It is unclear to me what is the use-case for the "file local data"; can a single DynasmData be used?

So far it seems that it is not a huge scope of work. I can give it a try.