Reexport likely/unlikely in std::hint

[x17jiri]

Since likely/unlikely should be working now, we could reexport them in std::hint. I'm not sure if this is already approved or if it requires approval

Tracking issue: #26179

[rustbot]

r? @workingjubilee

rustbot has assigned @workingjubilee.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ChrisDenton]

This would need lang and libs-api to look over. I'd note that the discussion in the tracking issue seems to be saying that this is the wrong API. In particular a #[cold] attribute or maybe a cold_path() function would be a better way forward.

[Noratrieb]

Yes, I agree with #26179 (comment) that likely/unlikely is the wrong API (the current implementation makes it look very silly, a roundabout way to just use cold_path) and I think we should move forward with cold_path, it's extremely simple and more reliable than likely/unlikely (and maybe #[cold] for match arms).

I think the next step would be to create an ACP for cold_path: https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html

[x17jiri]

cold_path() will need an update in the codegen to make it more useful. If we decide it's the way to go, I can work on ït.

Basically the current implementation gathers information about which code paths are cold, but this information is only used in select with 2 options. This was all I needed to fix likely and unlikely and I didn't want to make the PR bigger than needed.

However common patterns in Rust generate select with more than 2 options. For example this code:

if let Some(x) = t { ... }

May generate something equivalent to:

match t.discriminator {
1 => true branch,
0 => false branch, 
_ => unreachable
}

[workingjubilee]

"the compiler currently doesn't support the better option" sounds fixable.

[x17jiri]

@workingjubilee I'm all for improving cold_path(). I'm the guy who invented it. I even said I can work on it :-)

But likely and unlikely are more readable in some situations. For example if likely(cond) { ... } vs if cond { ... } else { cold_path() }. You can also use hem for parts of conditions. For example if a && likely(b) { ... }

And since there is RFC I thought they may already be approved

[tgross35]

If we had hint::cold_path() then we wouldn't need #[cold] on if/match (#120193) right? But if we instead had likely/unlikely, we would still need something different for match? Keeping things consolidated to a single feature seems like a nice advantage to me (we do already have #[cold] but applying attributes to match arms is pretty novel).

In any case you should file an ACP at https://github.com/rust-lang/libs-team/issues (it's just an issue template) for adding something new in hint.

And since there is RFC I thought they may already be approved

Given it was accepted about a decade ago, there is a good chance it would have to be revisited anyway :)

[x17jiri]

@tgross35 I'd like to have both likely/unlikely and cold_path, because cold_path can sometimes be awkward.

For example, I think:

if likely(cond) { ... }

is more readable than:

if cond { ... } else { cold_path() }

I'll look into the ACP and try to create one for all of these functions.

[tgross35]

I agree it's not the most convenient when you have one branch that you want to prioritize rather than deprioritizing all others, for either cold_path() or #[cold]. In theory could we also have hint::hot_path()? Not saying we necessarily want both, but this would also work better than likely for match arms.

[workingjubilee]

it might be useful to review https://blog.aaronballman.com/2020/08/dont-use-the-likely-or-unlikely-attributes/ which raises some relevant concerns.