Skip to content

transpile: unconditionally make consts use unsafe blocks for --translate-const-macros conservative#1335

Merged
kkysen merged 1 commit intomasterfrom
kkysen/const-macros-unsafe-block
Aug 29, 2025
Merged

transpile: unconditionally make consts use unsafe blocks for --translate-const-macros conservative#1335
kkysen merged 1 commit intomasterfrom
kkysen/const-macros-unsafe-block

Conversation

@kkysen
Copy link
Copy Markdown
Contributor

@kkysen kkysen commented Aug 21, 2025

Some operations, such as ptr arithmetic, are unsafe and can be done in const macros. So as an initially overly conservative implementation, just make all consts use unsafe blocks in case unsafe operations are used. This is what we already do for fns, for example, even if all of the operations in a fn are safe. We can improve this, but for now, this works and is correct.

@kkysen kkysen requested a review from fw-immunant August 21, 2025 00:06
Copy link
Copy Markdown
Contributor Author

@kkysen kkysen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kkysen kkysen force-pushed the kkysen/macro-IndexMaps branch from b9834b2 to 3eec9fa Compare August 21, 2025 06:13
@kkysen kkysen force-pushed the kkysen/const-macros-unsafe-block branch from 1e48cb0 to 14ca587 Compare August 21, 2025 06:13
Base automatically changed from kkysen/macro-IndexMaps to master August 21, 2025 19:16
…ranslate-const-macros conservative`

Some operations, such as ptr arithmetic, are `unsafe` and can be done in const macros.
So as an initially overly conservative implementation,
just make all `const`s use `unsafe` blocks in case `unsafe` operations are used.
This is what we already do for `fn`s, for example,
even if all of the operations in a `fn` are safe.
@kkysen kkysen force-pushed the kkysen/const-macros-unsafe-block branch from 14ca587 to 3635b4e Compare August 21, 2025 19:18
Copy link
Copy Markdown
Contributor

@fw-immunant fw-immunant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes our translation of a simple #define FOO 5 less idiomatic, which seems contrary to the goal of providing fully idiomatic translation for the simplest cases of #defines. I've prototyped an alternate strategy to adding unsafe to const macro translations where necessary in #1339.

Copy link
Copy Markdown
Contributor Author

@kkysen kkysen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes our translation of a simple #define FOO 5 less idiomatic, which seems contrary to the goal of providing fully idiomatic translation for the simplest cases of #defines.

I'm not sure if the goal was to provide fully idiomatic translation for the simplest #defines. We've never strived for c2rust transpile emitting fully idiomatic code, but rather, as idiomatic as reasonably possible. I'd like to merge this first as the simplest way to translate more const macros, and then we can work on things like #1339 on top of this (I'll leave more comments there). You made #1339 point at #1306, which points at #1335 (this PR), which seems like the right ordering to me, so if that's what you intended, then can we merge this PR now?

@fw-immunant
Copy link
Copy Markdown
Contributor

This makes our translation of a simple #define FOO 5 less idiomatic, which seems contrary to the goal of providing fully idiomatic translation for the simplest cases of #defines.

I'm not sure if the goal was to provide fully idiomatic translation for the simplest #defines. We've never strived for c2rust transpile emitting fully idiomatic code, but rather, as idiomatic as reasonably possible. I'd like to merge this first as the simplest way to translate more const macros, and then we can work on things like #1339 on top of this (I'll leave more comments there). You made #1339 point at #1306, which points at #1335 (this PR), which seems like the right ordering to me, so if that's what you intended, then can we merge this PR now?

That's what I understood from the phrase "low-hanging fruit"--the simple cases where we can get the exact right answer (fully idiomatic translation) without necessarily having a solution that can handle the full generality of inputs. Maybe @thedataking could clarify what our priorities are here.

I'd rather not merge this because it makes translation of simple uses of #define noticeably less idiomatic, which will be visible to any users of master (e.g. godbolt.org afaiu). #1339 reverts this change, and my intent was to merge 1339 into its target branch rather than master--if I wanted to merge it into master I would have set its PR target to that.

#1306 is approved and can merge into this branch whenever you like.

Copy link
Copy Markdown
Contributor

@fw-immunant fw-immunant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed the various const macro changes in flight and decided to land this and follow-ups rather than trying to stage everything outside master.

@kkysen kkysen merged commit c589c0a into master Aug 29, 2025
5 checks passed
@kkysen kkysen deleted the kkysen/const-macros-unsafe-block branch August 29, 2025 20:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants