-
Notifications
You must be signed in to change notification settings - Fork 277
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_ty
s 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 fn
s. 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.