`indexing_slicing` should not fire if a valid array index comes from a constant function that is evaluated at compile-time

[c410-f3r]

1. From a inline constant block (indexing_slicing should not fire if a valid array index comes from a constant function that is evaluated at compile-time #8348 (comment)).

#![feature(inline_const)]
#![forbid(clippy::indexing_slicing)]

const FOO: [i32; 1] = [1];

const fn idx() -> usize {
    0
}

pub fn main() {
    assert_eq!(FOO[const { idx() }], 1);
}

2. From a const declaration (indexing_slicing should not fire if a valid array index comes from a constant function that is evaluated at compile-time #8348 (comment)).

#![forbid(clippy::indexing_slicing)]

const FOO: [i32; 1] = [1];
const REF: &i32 = &FOO[idx()];

const fn idx() -> usize {
    0
}

pub fn main() {
  assert_eq!(REF, &1);
}

[xFrednet]

I think here we should distinguish if the type is an array with a fixed size, as that will be caught by the compiler or a slice. The lint should still trigger in the later case, as the range check will be done at runtime. This should be a simple type check 🙃

@rustbot label +good-first-issue

[camsteffen]

I think this is functioning as designed. const functions are not evaluated at compile-time unless it is in a const context. If you change idx to return 1, it will compile without warning and panic at runtime. Note that this is a restriction lint so it's generally not recommended unless you have a specific reason to use it.

[PatchMixolydic]

Here's a disassembly of a similar code snippet showing that the call to idx isn't necessarily evaluated at compile time. Incidentally, this lint still trips when the compiler is forced to evaluate idx() at compile time using an inline const block (playground):

#![feature(inline_const)]
#![forbid(clippy::indexing_slicing)]

const FOO: [i32; 1] = [1];

const fn idx() -> usize {
    0
}

pub fn main() {
    assert_eq!(FOO[const { idx() }], 1);
}

error: indexing may panic
  --> src/main.rs:11:16
   |
11 |     assert_eq!(FOO[const { idx() }], 1);
   |                ^^^^^^^^^^^^^^^^^^^^
   |
note: the lint level is defined here
  --> src/main.rs:2:11
   |
2  | #![forbid(clippy::indexing_slicing)]
   |           ^^^^^^^^^^^^^^^^^^^^^^^^
   = help: consider using `.get(n)` or `.get_mut(n)` instead
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#indexing_slicing

This should presumably be allowed for the same reason as normal array indexing (any misuse would be caught by const_err).

[c410-f3r]

const functions are not evaluated at compile-time unless it is in a const context

Here's a disassembly of a similar code snippet showing that the call to idx isn't necessarily evaluated at compile time.

Oh, I forgot about this feature. Thanks for pointing out such behavior.

In addition to what @PatchMixolydic said, the following snippet should also not fire indexing_slicing:

#![forbid(clippy::indexing_slicing)]

const FOO: [i32; 1] = [1];
const REF: &i32 = &FOO[idx()];

const fn idx() -> usize {
    0
}

pub fn main() {
  assert_eq!(REF, &1);
}

[c410-f3r]

Updated the issue based on the provided feedback

[pitaj]

@rustbot claim

[c410-f3r]

Thanks @pitaj