Is proc_macro_hygiene still needed?

[HadrienG2]

I recently ended up on this library, and noticed that it did not compile on stable due to use of the proc_macro_hygiene nightly feature.

Since there's been some movement on proc macro stabilization recently, I figured I'd just try to remove the feature gate and see what happens, and the result builds on stable and seems to produce correct mathematical results (validated against rug/MPFR).

Are you sure you still need this feature gate?

[jkarns275]

So I'm not entirely sure what i even used that for. This is where the proc_macro gets used to construct the f128 input macro

f128/src/lib.rs

Lines 9 to 15 in b5012f0

	#[macro_export]
	macro_rules! f128 {
	($e:expr) => (f128_inner!($e));
	($f:expr, $($e:expr),+) => ((f128_inner!($f), $(f128_inner!($e)),+));
	[$f:expr, $($e:expr),+] => ([f128_inner!($f), $(f128_inner!($e)),+]);
	[$f:expr; $l:expr] => ([f128_inner!($f); $l]);
	}

Does this look like it would compile on stable? (where f128_inner is a proc_macro)
I haven't been keeping up with the new versions of rust lately

[HadrienG2]

This looks like the "fn-like proc macro expanding to an expression or statement" feature gate, which was stabilized last summer through this PR that shipped in Rust 1.45 last July.

And empirically speaking, I checked that if I just remove the feature gate, the crate builds on stable and seems to behave as intended.

[jkarns275]

Alright, I'll remove this and push out a new version of the crate today. Thanks for pointing this out.

[jkarns275]

Okay this was fixed with ebd3b21

[HadrienG2]

Thanks!