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

librustc_llvm: encapsulate "as" cast from/to a bool #32700

Closed
wants to merge 1 commit into from

Conversation

nodakai
Copy link
Contributor

@nodakai nodakai commented Apr 3, 2016

When the trueness is defined as "!= 0" rather than "== 1", it's error prone to write such a comparison for each occurrence.

@rust-highfive
Copy link
Collaborator

r? @arielb1

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

@@ -2720,7 +2720,7 @@ pub fn trans_crate<'tcx>(tcx: &TyCtxt<'tcx>,
static INIT: Once = Once::new();
static mut POISONED: bool = false;
INIT.call_once(|| {
if llvm::LLVMStartMultithreaded() != 1 {
if ! llvm::as_bool(llvm::LLVMStartMultithreaded()) {
Copy link
Member

Choose a reason for hiding this comment

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

Stylistically we tend to not have spaces after the ! operator

@alexcrichton
Copy link
Member

This seems like it may be a difficult convention to follow as it's easier to just call the function directly and not call an extra function to wrap the result. How do we ensure that we avoid adding more as casts in the future?

When the trueness is defined as "!= 0" rather than "== 1", it's error
prone to write such a comparison for each occurrence.

Signed-off-by: NODA, Kai <nodakai@gmail.com>
@nodakai
Copy link
Contributor Author

nodakai commented Apr 10, 2016

@alexcrichton True, when the underlying APIs themselves have a confusing interface, I can only hope someone modifying this potion of code notices the Bool type has its wrapper functions which are defined 5 lines below it.

@alexcrichton
Copy link
Member

I guess my point is that I don't think this is worth it unless we have a deeper change. We're not currently in the mindset of avoiding as as much as possible, so any new calls to LLVM apis will continue to cast bools. Essentially it's easier to use as than it is to use the functions you've added, so the ergonomics are going the wrong way.

@bors
Copy link
Contributor

bors commented Apr 20, 2016

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

@nagisa
Copy link
Member

nagisa commented May 3, 2016

Should this be closed?

@nodakai
Copy link
Contributor Author

nodakai commented May 3, 2016

No.

野田 開 nodakai@gmail.com

2016-05-04 1:19 GMT+08:00 Simonas Kazlauskas notifications@github.com:

Should this be closed?


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#32700 (comment)

@alexcrichton
Copy link
Member

Closing due to inactivity, but feel free to reopen with a rebase!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants