-
Notifications
You must be signed in to change notification settings - Fork 281
Description
The combination of #1266 and #1305 caused an issue with how const macro translation and portable types are implemented.
With #1266 adding support for portable types, override_tys were threaded through fn convert_expr's call tree containing the overriding portable type.
However, in translating const macros, we started from the expansion exprs to recreate the const macro. This lacked the parent fn convert_expr tree that piped down the correct override_ty, so we end up translating const macros with a non-portable type, and then when the const macro is used, we get type errors.
Getting the correct override_ty to the const macros is tricky because the const macros can be translated before their uses, so we haven't yet determined the correct override_ty. Likely, we want to separate the portable type/override_ty determination into a separate stage of the transpiler that runs before all fn convert_* functions, but as that's a bigger change and I want to make sure I'm doing the right thing and not missing something, I'll go for a simpler solution first: just adding casts at all const macro use sites to the correct portable type, as we do have the override_ty available when translating the const macro expansions, just not the const macro itself.
Alternatively, we could take an approach like #1295 (comment) and translate const macros as plain (sometimes const) generic fns. This is more similar to how C macros work, with the expansion happening at use site, instead of having to have a singular definition that works for all uses. Using a generic here would allow the type to be determined at the use/call site, which is simpler to do as described above.