Stabilize const_int_ops integer methods

[faern]

Fixes #51267 (tracking issue)
Stabilizing the methods made const fns in #51299

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[nikomatsakis]

Hmm, cc @oli-obk and @eddyb — I am mildly reluctant here on the basis of our ongoing discussion about just how to handle const fn when it comes to promotion and so forth. Thoughts? Should we put a hold on const fn stabilization?

[oli-obk]

These const fns in particular are very simple numerical const fns. I was just about to write that these are totally fine, because they have no failure cases. Any integral input will result in a valid value...

And then realized that if you casted a reference to a pointer and then to a usize and then applied these functions, const eval would abort with an error, because you can't swap bytes of an abstract pointer, or count the ones in it. And we also cannot provide a value that will be exactly what you'd get at compile-time, because we don't know the compile-time address.

This is exactly the same issue as comparing any value derived from an address.

It is kind of fine to stabilize them because there's no way to obtain the address of anything as a value of integral type in promoteds (unions are forbidden, casting pointers to usize is forbidden). Outside of promoteds it's also fine, because you need to change code in order to get a compilation failure.

That said, we definitely need regression tests that try very hard to use these on addresses in promoteds .

[eddyb]

cc @rust-lang/libs These functions were made const fn days ago.
I'm not sure if we have a process here, but this needs at least (the time of) FCP, right?

[faern]

I might have submitted the stabilization PR too early. It's my first PR on stabilization of anything so I'm not sure what the process is. I got the impression that stabilizing const fns was fairly uncontroversial so I felt I could try. Feel free to educate me on how to proceed from here :)

[nikomatsakis]

@oli-obk I have to say that this sort of ad-hoc logic makes me uncomfortable. =) That is, it feels easy for us to overlook some conditions or be a bit surprised... maybe we just need to commit to const fns exposing their bodies somehow when it comes to promotion. That said, didn't we say that we were going to have some special attribute that would allow us to promote const fns for now? In that case, I would worry a lot less.

[oli-obk]

Yes, I haven't gotten around to writing that feature gate yet.

My post might have come off too much in support of stabilizing. I do worry about these const fns because in contrast to the other stable const fns, these ones do more than just create structs

[nikomatsakis]

I am personally opposed to stabilizing any more const fn until we have some way to limit which const fn will potentially be promoted. (cc @rust-lang/libs)

(Note to @faern — I don't want you to interpret this as a rebuke. It's just that we recently found some soundness issues around the way the compiler was handling const fn promotion, and so I want to tread carefully!)

[SimonSapin]

@nikomatsakis What does promotion mean in this context?

[hanna-kruppe]

Promotion of values to 'static, i.e., allowing let x: &'static _ = &<some expression>; to compile.

[faern]

@nikomatsakis Fully understood! I don't interpret any of this as a rebuke towards me. Even though I would want this feature, I much more want the compiler/language to be sound :)

[pietroalbini]

Ping from triage! What's the status of this PR?

[oli-obk]

blocked on #51570

[bors]

☔ The latest upstream changes (presumably #51717) made this pull request unmergeable. Please resolve the merge conflicts.

[kennytm]

@oli-obk Since #51570 has been closed, what should be done to this PR?

[oli-obk]

@nikomatsakis Since there is no safe way to construct a constant that can be given to these functions as an argument and then fail evaluation, it seems fine to merge these.

Also we are explicitly forbidding unions in promoteds (http://play.rust-lang.org/?gist=817735ebe9b1cfd56042819d4bcf545e&version=stable&mode=debug&edition=2015) and casting raw pointers to integers, so these functions becoming const fn cannot cause working runtime code to suddenly produce an error.

That said. Until this is the RFCed strategy for const safety, we should probably just close this.

[rust-highfive]

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[nikomatsakis]

I'm inclined to close this until we have a chosen strategy. Going to do so. Thanks @faern for the PR, in any case! =)