tracking issue for `const_indexing` stabilization

[oli-obk]

The feature called const_indexing allows the indexing operation to be performed while calculating a true constant like an array length.

See the implementation at #25570

[debris]

I've updated rust nightly today and i've stumbled upon const_indexing issue in my lib.

const indexing is an unstable feature

The code was compiling fine on 1.4.0, beta and old nightly, so I assume it might be the issue with new feature itself, not my code. After quick investigation I worked around the issue in this commit: debris/tiny-keccak@591d611 . Hope it helps with stabilization!

[oli-obk]

oh... not good. I know what's going on. You are using the index operation on the rhs of a bitshift operation. So during check_const the rhs is const_evaled, which triggers this... Fixing this makes the code rather ugly. Basically I need to make sure that during compiler checks no feature gate errors are emitted but simply const eval fails...

[frewsxcv]

A similar regression also happened here: ende76/brotli-rs#14

[nikomatsakis]

@eddyb do you see any reason not to stabilize this? Seems like we're going to wind up with a model that supports this sort of thing, at least in some cases.

[eddyb]

The actual addresses would be different... probably fine though, we already do the same thing in trans.
EDIT: ignore me, this only matters in trans. If qualify_consts passes then miri likely can eval it.
@oli-obk @solson Any objections regarding miri? Doubt it but just in case.

[solson]

Indexing will force allocations in miri, unlike most things supported by legacy const eval, but it wouldn't be the only thing (e.g. I think *&42 is valid in consts today). It sounds fine.

[quadrupleslap]

Is this going to be stabilised soon? I tried it on stable, and it works without any issues, but it's feature-gated only on nightly. Why does it seem to work on stable?

[oli-obk]

@quadrupleslap: that sounds buggy, can you give an example code exhibiting that behaviour?