[BUG] Type deduction deduces a pointer from an int

[threeifbyair]

When creating a variable using >> or & on an integral type, somehow the deduced type is some kind of pointer rather than an integer.

https://cpp2.godbolt.org/z/sf4Y7MxMz

bar: (foo: uint32_t) -> uint32_t = {
    x := foo >> 16;
    y := foo & 0xFFFF;
    return (x+1) ^ (y-1);
}

gives

example.cpp2(4,22): error: - - pointer arithmetic is illegal - use std::span or gsl::span instead
  ==> program violates bounds safety guarantee - see previous errors

If I explicitly say that y is a uint32_t, everything is fine, but why does cppfront think that it's a pointer?
(I've seen the same issue with x, but it doesn't reproduce in this example.)

[gregmarr]

Very weird. This works:

z := x + y; 
return (x+1) ^ (z-1);

Something is definitely off in the bounds safety check.

[zaucy]

I believe its because foo & is being interpreted as foo address by mistake? Adding parenthesis seems to work as well

bar: (foo: uint32_t) -> uint32_t = {
    x := foo >> 16;
    y := (foo) & 0xFFFF;
    return (x+1) ^ (y-1);
}

[gregmarr]

Yes, but this means that it's going back to the line where y is declared to determine whether it's a pointer or not, and not parsing it properly, which seems odd to me.

[dhthwy]

Yeah, it seems to be parsing as

(foo&) 0xFFFF

where the 0xFFFF is handled as if doesn't exist.

which should be an ill formed expression (and it is with the parens there)

But what about

y := foo && 0xFFF;

Is that a logical and or take the address of foo and bit and?

Seems to be some ambiguity to flesh out.

[hsutter]

Fixed by #1360