Make time::Instant::actually_monotonic() a const fn.

[shamiao]

No description provided.

[rust-highfive]

r? @kennytm

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

[kennytm]

Could you provide any context why this is needed? AFAIK actually_monotonic() is only used in Instant::now() which won't be const.

[shamiao]

This PR mainly prevents anyone from accidentally adding code which introduces runtime penalty to actually_monotonic().

This also removes an unnecessary call to actually_monotonic() at every time Instant::now() is called for debug builds. (EDIT: doesn't make sense. thanks @sinkuu for pointing out)

note: AFAIK monotonicity only depends on platform and build configurations and won't change at runtime.

[sinkuu]

This also removes an unnecessary call to actually_monotonic() at every time Instant::now() is called for debug builds.

Compile-time evaluation does not happen when const fn is called from non-const context:

constfnfoo() -> bool{true}pubfnbar() -> bool{foo()}

; playground::foo; Function Attrs: nonlazybind uwtabledefineinternalzeroexti1@_ZN10playground3foo17h3b9711775736012fE() unnamed_addr #0!dbg!5 {
start:
reti1true, !dbg!10
}
; playground::bar; Function Attrs: nonlazybind uwtabledefinezeroexti1@_ZN10playground3bar17hfc942ebdcf035a2cE() unnamed_addr #0!dbg!11 {
start:
; call playground::foo%0 = callzeroexti1@_ZN10playground3foo17h3b9711775736012fE(), !dbg!12brlabel%bb1, !dbg!12
bb1: ; preds = %startreti1%0, !dbg!13
}

EDIT: Also, std is compiled in release mode, so actually_monotonic() call should be aleady inlined.

[shamiao]

@sinkuu Sorry, this is my mistake. But I wonder why the compiler doesn't evaluate it?

[sinkuu]

@shamiaoconst fn just enables functions "to be called in constants contexts". Evaluating const fn in non-const context is rather an optimization, and compiler devs seem to have the plan (#64996 (comment)).

[joelpalmer]

Ping from Triage: Any updates @shamiao

[shamiao]

@joelpalmer I have no further updates. Waiting the Rust crew to decide whether this PR should be merged.

[JohnCSimon]

Ping from triage:
@kennytm Can you please review/merge this PR?
CC: @shamiao

Thanks!

[kennytm]

IMO the reason making this a const fn isn't compelling enough, as

1. this function is never used in const context
2. this function is private
3. the optimizer will certainly evaluate and inline these trivial functions, regardless of constness

So I'd prefer to close this PR.

[shamiao]

@kennytm Opinion 3 seems compelling to me. I'll close this PR.