Implement conservative subset of `--translate-const-macros`

[fw-immunant]

--translate-const-macros in its full generality is very hard to implement, because it's quite difficult to determine if nontrivial expessions will be const-safe; see this comment. It seems like it may not be worth the effort to make the implementation much more complex because it will never cover all possible uses of even non-function-like C macros.

That said, it's annoying that we don't have a way to pick the low-hanging fruit here without attempting to tackle the thornier issues. We should implement a minimal implementation of similar functionality that handles #define NAME literal and then in a follow-up expand to handle a minimal conservative subset of expressions such as variable references and binary/unary/paren expressions. By staying extremely conservative we can sidestep the const safety question entirely for now.

We might implement this as a mode/argument for the existing --translate-const-macros flag, but in any case we want whatever we come up with to be enabled by default, which means it needs solid testing.

[kkysen]

To expand this further beyond literals, I think it may be better to implement this moreso outside of the transpiler. That is, we currently try to translate const macros to rust consts. To do so, we need to ensure all of the operations are const-compatible. And some are unsafe, so we need to add unsafe {} blocks for them as well. If these fail, then we just translate it as nothing.

Instead, I think it would be better to translate all const macros (and probably fn macros) as non-const unsafe fns in Rust. We should be able to do this in far more cases, as we don't have to worry if operations are const, and we can use unsafe operations as well. Then we just replace the macro expansions with a call to this function instead of a const item.

For example, in the #853 case, this will successfully translate it even though the operations are not const.

Then we can, optionally, do a secondary analysis to make things as const and safe as possible, which is also more generally applicable. We can add const to any fn where it's possible and then bubble that up (see clippy::missing_const_for_fn). And we could do the same for removing unsafe from fns that are already safe.

@fw-immunant, what do you think?

Or I can do the const analysis in the transpiler. And I can also either do an unsafe analysis, or just put everything in an unsafe block even if it may be safe (like we do for some functions that are completely safe right now).

[kkysen]

For CExprKind::ConstantExpr expansions, we'll have to do either a const or const fn, but for other expansions, we should have a lot more flexibility to use non-const fns.

[fw-immunant]

To expand this further beyond literals, I think it may be better to implement this moreso outside of the transpiler. That is, we currently try to translate const macros to rust consts. To do so, we need to ensure all of the operations are const-compatible. And some are unsafe, so we need to add unsafe {} blocks for them as well. If these fail, then we just translate it as nothing.

Instead, I think it would be better to translate all const macros (and probably fn macros) as non-const unsafe fns in Rust. We should be able to do this in far more cases, as we don't have to worry if operations are const, and we can use unsafe operations as well. Then we just replace the macro expansions with a call to this function instead of a const item.

If I understand correctly, it seems like you're saying the advantage here is that this strategy allows us to cover as many cases as possible. The downside is that for all cases it introduces less idiomatic translation involving a function call and a non-const function.

I think instead we want to identify more (but not all) cases in which we can produce the ideal, most idiomatic translation. Our priority is not covering the absolute most inputs (as there will always be macros that don't expand to entire expressions, for example) but instead producing highly idiomatic translations in the subset of cases where this is straightforward to do. The next cases we want to cover are probably the transitive closure of some subset of CExprKind variants such as parenthesized expressions and some cases of binary/unary operations. Casts are probably also a reasonable thing to extend to.

For example, in the #853 case, this will successfully translate it even though the operations are not const.

I don't actually see what #853 has to do with const; it seems to be a bug in our reasoning about types.

Then we can, optionally, do a secondary analysis to make things as const and safe as possible, which is also more generally applicable. We can add const to any fn where it's possible and then bubble that up (see clippy::missing_const_for_fn). And we could do the same for removing unsafe from fns that are already safe.

@fw-immunant, what do you think?

Or I can do the const analysis in the transpiler. And I can also either do an unsafe analysis, or just put everything in an unsafe block even if it may be safe (like we do for some functions that are completely safe right now).

This seems like the opposite side of the equation: producing a more general translation that can cover all cases. This might be what we would eventually want to do for the cases that fall outside of our conservative subset when using the full/"experimental" --translate-const-macros mode, but I think this is outside of the scope of this bug. It's probably worth discussing this with @Perl in the loop for more guidance on direction.

[kkysen]

If I understand correctly, it seems like you're saying the advantage here is that this strategy allows us to cover as many cases as possible. The downside is that for all cases it introduces less idiomatic translation involving a function call and a non-const function.

I'm saying that it covers as many cases as possible and is a more idiomatic translation. C macros (and Rust macros) do not require an intermediate constant and are fully inlined. This is much more similar to a function call.

I think instead we want to identify more (but not all) cases in which we can produce the ideal, most idiomatic translation. Our priority is not covering the absolute most inputs (as there will always be macros that don't expand to entire expressions, for example) but instead producing highly idiomatic translations in the subset of cases where this is straightforward to do. The next cases we want to cover are probably the transitive closure of some subset of CExprKind variants such as parenthesized expressions and some cases of binary/unary operations. Casts are probably also a reasonable thing to extend to.

#1306 already does pretty much this for a significant number of cases, anything that's const (besides statements, which I'm still implementing). I'm asking about after that.

For example, in the #853 case, this will successfully translate it even though the operations are not const.

I don't actually see what #853 has to do with const; it seems to be a bug in our reasoning about types.

I think I may have cited the wrong issue. I think I meant #803. Which #1306 won't translate, and the const approach simply will never work.