gccrs does not check if something is assignable

[liushuyu]

Summary

gccrs does not check if something is assignable, and gccrs accepts many un-assignable expressions.

Reproducer

I tried this code:

fn main() -> i32 {
    let mut x = 42;
    x + 1 = 2;

    x
}

Does the code make use of any (1.49) nightly feature ?

• Nightly

Godbolt link

No response

Actual behavior

The current behavior is that gccrs accepts this kind of semantically invalid code and even successfully generates machine code for them (in this case, gccrs generates code to make the function return 42).

Expected behavior

I expected to see an error thrown like rustc does:

error[E0070]: invalid left-hand side of assignment
 --> test1.rs:3:11
  |
3 |     x + 1 = 2;
  |     ----- ^
  |     |
  |     cannot assign to this expression

GCC Version

fa93e28

[philberty]

I've purposely not tackled this because i have a feeling implementing a walk tree function like we do inside:

https://github.com/Rust-GCC/gccrs/blob/master/gcc/rust/checks/lints/rust-lint-unused-var.cc

and looking for the assignment expressions and checking the const qualifiers might be enough. But it probably wont be perfect it needs some though with someone with free time

[philberty]

There is a better way to implement this by copying some of the code from the c front-end: We need a check in our assignment expression during code generation which is here:

gccrs/gcc/rust/backend/rust-compile-expr.cc

Line 988 in 55a9d8d

tree assignment

Where we need to port over this function from the c front-end:

gccrs/gcc/c/c-typeck.cc

Line 5165 in 55a9d8d

lvalue_p (const_tree ref)

This will tell us true or false if its a valid lvalue so then if its not we can emit a rust_error_at diagnostic.

[CohenArthur]

how complicated would that be compared to making a simple visitor on our side? I feel like there's two different things, checking if it's a proper lvalue and checking if it's mutable - both of which would be implemented super quickly with one of our custom visitors

[philberty]

Yeah i think its two issues that need seperated

[philberty]

part of the issue is the overflow traps return a var decl which is what we want so i think we need to use the lvalue check from c fropnmt-end and something on our HIR as well where yes GCC wise its a var devel but this HIR expr is an operator so its definetly not an lvalue

[philberty]

I sort of think another tree walker could do the assignment check and look if the lvalue is TREE_READONLY but not totally sure it handles it properly for rust

[philberty]

this solves the mutability checks for this case:

#3311