Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify likely! and unlikely! macro #97895

Merged
merged 1 commit into from
Jun 22, 2022
Merged

Conversation

nbdd0121
Copy link
Contributor

@nbdd0121 nbdd0121 commented Jun 8, 2022

The corresponding intrinsics have long been safe-to-call, so the unsafe block is no longer needed.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 8, 2022
@rust-highfive
Copy link
Collaborator

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 8, 2022
@CryZe
Copy link
Contributor

CryZe commented Jun 8, 2022

Are these macros even needed then?

@nbdd0121
Copy link
Contributor Author

nbdd0121 commented Jun 8, 2022

Personally I feel use a macro is better than direct use of intrinsics (it's easier to replace the implementation to a no-op if intrinsics use is to be avoided).

With that said, an re-export could serve the same purpose. Or maybe we don't even need to worry about that given that the code in the compiler itself so the intrinsics won't go away.

@estebank
Copy link
Contributor

Funnily enough, I didn't find any uses of likely! and only 37 uses of unlikely!. I'd be ok with replacing the macro with the intrinsic reexport.

Anyone against removing the macros, @rust-lang/compiler?

@tschuett
Copy link

I prefer the macros. They read different than the intrinsics.

@davidtwco
Copy link
Member

#[likely] and #[unlikely] attributes have been floated as a possibility in the tracking issue (#26179 (comment)).

@lcnr
Copy link
Contributor

lcnr commented Jun 13, 2022

I would prefer to use the functions directly if the macros don't add any new behavior 🤷

@tschuett
Copy link

C++20 went for attributes. The if or else branch are likely and not the value.

@michaelwoerister
Copy link
Member

Using the intrinsic directly seems preferable to me. I suspect the macros were mostly for convenience when this still required unsafe.

@estebank
Copy link
Contributor

@nbdd0121 would you mind removing the macros and using the intrinsic directly? I think that'll be better given the context we have at the moment.

@nbdd0121
Copy link
Contributor Author

Re-export or direct use?

@estebank
Copy link
Contributor

Re-export is fine, but direct use might be better.

@nbdd0121
Copy link
Contributor Author

Done.

The unlikely! macro in library is for a different purpose (to use allow_internal_unstable) so that's untouched (turns out the unlikely! in library is introduced by myself, but I totally forgot that).

@@ -804,7 +804,7 @@ pub type PolyTraitPredicate<'tcx> = ty::Binder<'tcx, TraitPredicate<'tcx>>;

impl<'tcx> TraitPredicate<'tcx> {
pub fn remap_constness(&mut self, tcx: TyCtxt<'tcx>, param_env: &mut ParamEnv<'tcx>) {
if unlikely!(Some(self.trait_ref.def_id) == tcx.lang_items().drop_trait()) {
if std::intrinsics::unlikely(Some(self.trait_ref.def_id) == tcx.lang_items().drop_trait()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we remove this now?

cc @fee1-dead

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this should be removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be clear, this isn't something for me to action on, right?

Copy link
Member

@fee1-dead fee1-dead Jun 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I have added it to my to-do list. Although if you would allow me, I can just edit this PR to include the removal of this chunk :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say probably it's better to have this PR merged first (cuz the changes are not really correlated so doesn't really fit into a single PR in my mind). @estebank are there anything blocking you from r+ing this PR?

@estebank
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Jun 21, 2022

📌 Commit 8b7299d has been approved by estebank

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 21, 2022
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Jun 22, 2022
Simplify `likely!` and `unlikely!` macro

The corresponding intrinsics have long been safe-to-call, so the unsafe block is no longer needed.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 22, 2022
Rollup of 10 pull requests

Successful merges:

 - rust-lang#95446 (update CPU usage script)
 - rust-lang#96768 (Use futex based thread parker on Fuchsia.)
 - rust-lang#97454 (Add release notes for 1.62)
 - rust-lang#97516 (clarify how Rust atomics correspond to C++ atomics)
 - rust-lang#97818 (Point at return expression for RPIT-related error)
 - rust-lang#97895 (Simplify `likely!` and `unlikely!` macro)
 - rust-lang#98005 (Add some tests for impossible bounds)
 - rust-lang#98226 (Document unstable `--extern` options)
 - rust-lang#98356 (Add missing period)
 - rust-lang#98363 (remove use of &Alloc in btree tests)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 8f861da into rust-lang:master Jun 22, 2022
@rustbot rustbot added this to the 1.63.0 milestone Jun 22, 2022
@nbdd0121 nbdd0121 deleted the unlikely branch October 5, 2022 22:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.