gccrs: Diagnose unsigned arithmetic overflow in constant evaluation

[u7k4rs6]

Rust errors on const-eval overflow even for unsigned, but GCC only sets TREE_OVERFLOW for signed ops (unsigned wraparound is defined in C), so the rust-constexpr.cc check never catches it.

Check before folding instead; this covers addition, subtraction and multiplication on statically-known operands in const context.

gcc/rust/ChangeLog:

* backend/rust-compile-expr.cc (CompileExpr::visit): Detect unsigned overflow during constant evaluation before operands are folded.

gcc/testsuite/ChangeLog:

* rust/compile/const_overflow_unsigned.rs: New test.

[CohenArthur]

This needs to use error code E0080 like rustc does. The message also does not have to conform to what GCC does and can be more explicit

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=fb7cea6709e2b9576f3769bf9fe60ee5

[CohenArthur]

Even if the const folder from C++ catches the error for signed types during const evals, the fact that we don't have a location is pretty annoying. It would be easy to change this to properly catch both signed and unsigned overflows. I would also suggest moving this into a separate function, and putting this in the typechecker rather than in the backend.

[CohenArthur]

This test needs to be split between checks for unsigned overflows and signed overflows

[u7k4rs6]

@CohenArthur Two things I'd like to confirm before implementing:

The const-context tracking that covers consts, statics, enum discriminants and array lengths lives in ConstChecker, so I'm planning to put the overflow check there. This requires using query_compile_const_expr from checks/errors/, which would be a new checks/ backend/ dependency.
Is that okay, or would you prefer keeping it in typecheck/?
Rustc reports overflow in const fn via the arithmetic_overflow lint rather than E0080, while ConstChecker currently treats const fn as const context. Should I exclude const fn here, or is E0080 acceptable for now?

[philberty]

This isnt the right place to add this check we should be doing this overflow check inside the const-expr code directly as a more general case.

[philberty]

This is the wrong place to implement this there are 2 places:

1. Constant items
2. Constant Blocks

Constant items will do constexpr eval which is not signalling overflow errors at the moment

See

tree
HIRCompileBase::compile_constant_item (
  HirId coercion_id, TyTy::BaseType *resolved_type,
  TyTy::BaseType *expected_type, const Resolver::CanonicalPath &canonical_path,
  HIR::Expr &const_value_expr, location_t locus, location_t expr_locus)
{

it calls fold_expr to call into our constant folder but we are missing this in fold_expr call in

void
CompileExpr::visit (HIR::AnonConst &expr)
{
  expr.get_inner_expr ().accept_vis (*this);
}

void
CompileExpr::visit (HIR::ConstBlock &expr)
{
  expr.get_const_expr ().accept_vis (*this);
}

Those need to do full const expr for inline const supprt.

We cant inline overflow checks like this it needs to be done in the constexpr.cc code.

[philberty]

before i forget we do const eval in a few other places like array capacity expr and statics

[u7k4rs6]

Thanks @philberty that makes sense, I'll move it into constexpr.cc.
Tracing it: eval_binary_expression (rust-constexpr.cc:3142) has lhs, rhs, code and type plus a real EXPR_LOCATION at :3166, before fold_binary_loc collapses things to an INTEGER_CST. That's why the existing signed overflow error at :1968 has no locus by the time it fires the location is gone.
Checking there fixes the location for signed and unsigned in one place, and since every const-eval path goes through fold_expr it covers const items, statics, array capacity and enum discriminants together. I'll model it on eval_check_shift_p and respect ctx->quiet.
@CohenArthur this lands in the const folder rather than codegen, I think it still gives you E0080, a proper location, and signed+unsigned in one check. Shout if you'd still rather it sat in the typechecker.

Two scope questions: should AnonConst/ConstBlock full const-eval go in this PR or a follow-up? And is E0080 acceptable for const fn bodies, where rustc uses the arithmetic_overflow lint instead?

[u7k4rs6]

Pushed a rewrite after iterating on the review comments.

The constexpr.cc approach didn't catch plain constant expressions because they're folded earlier in rust-gcc.cc. I moved the check by preventing that fold during const evaluation, so eval_check_overflow_p can catch both signed and unsigned overflow with the original location.

@CohenArthur E0080/rustc wording is in place, tests are split, and the line-0 workaround is gone. Uncalled const fn overflow remains undiagnosed, matching rustc's lint behavior.

make check-rust: 5524 passes, 0 failures. -m32 untested locally due to disabled multilib.

[philberty]

yeah we should make a follow up for const block and anon const to do a full const expr eval cant think off top of my head best way to implement that though because thats a block expr in consts and statics i basically turn it into a little function to const expr on hmm would have to take a look to remind myself of simplest way to implement that

[philberty]

yeah and "nd is E0080 acceptable for const fn bodies, where rustc uses the arithmetic_overflow lint instead?" seems grand it can be improved later on in my opinion if we want more granular error codes and flags

[u7k4rs6]

@philberty gentle ping on this one you answered both questions above (follow-up for const block/anon const, and E0080 being fine for const fn bodies for now), but the review is still marked as requesting changes so it's blocked. Could you take another look when you get a chance? CI is green.