Skip to content

transpile: const macros cause type errors as they aren't translated with portable types #1320

@kkysen

Description

@kkysen

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions