`@inbounds` in dead code taints consistency

[Keno]

function foo()
      false && @inbounds (1,2,3)[1]
      return 1
end

julia> Base.infer_effects(foo)
(!c,+e,+n,+t,+s,+m)

This likely regressed in #48158

[Keno]

On further thought, I'm not sure :inbounds actually needs to taint consistency at all. The thing that taints consistency is :boundscheck. If we didn't have --check-bounds=yes it would make a difference, but given that we have all the options, I'm not sure it does.

[gbaraldi]

In fact :inbounds might make it more consistent, since it won't give a bounds error ever, it will either segfault or return garbage, but indexing out of bounds is undefined anyway.

[Keno]

Consistency needs to be true for all argument values, since the compiler is allowed to invent them.

[gbaraldi]

But if we access outside of bounds and into potentially undefined memory, how can the compiler know what to put there?

[Keno]

The compiler doesn't, we need to prevent trying to concrete eval something that might invoke undefined behavior or in other words, undefined behavior taints :consistent.

[oscardssmith]

Could we make it so that indexing out of bounds at compile time semantically returned zero?

[gbaraldi]

If we knew at compile time that were indexing out of bounds we probably want to throw an error at compile time no?

[Keno]

You'd have to compile a separate copy of all functions, which is unlikely to be worth it. Also in general, you can't really do much with the results, because it's no longer a faithful model of the function being analyzed.