-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
libsyntax/librustc: Allow calling variadic foreign functions. #10064
Conversation
return token::DOTDOT; | ||
} | ||
return token::DOT; | ||
if nextch(rdr) != '.' { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like these if
s might be clearer worded as positives:
bump(rdr);
return if nextch(rdr) == '.' {
bump(rdr);
if nextch(rdr) == '.' {
bump(rdr);
token::DOTDOTDOT
} else {
token::DOTDOT
}
} else {
token::DOT
};
(at the very least, the inner most if
is clearer as a postive, and factoring out the common bump
s seems nicer.)
Cool! This should definitely be discussed. Some thoughts:
|
@alexcrichton I just put the variadic flag on |
Ah excellent! I need to read more closely next time. Otherwise this looks good to me with some tests. |
I'd like to review this too. |
bound_lifetime_names: opt_vec::Empty, // FIXME(#4846) | ||
inputs: inputs.clone(), | ||
output: output, | ||
variadic: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is definitely wrong. This bit of code checks for subtypes and combines types, so just ignoring variadic means that you could combine variadic and non-variadic fn types indiscriminately. What you want to do is to require that both a.variadic and b.variadic agree, and then use a.variadic in the result. Something like:
if a.variadic != b.variadic { return Err(ty::terr_variadic_mismatch(expected_found(a.variadic, b.variadic)); }
...
Ok(FnSig {
...
variadic: a.variadic
})
I'm ok with having this for extern fns, but am very, very strongly opposed to adding this feature for anything other than foreign function declarations. |
Does this need |
@Kimundi Not needed, but |
OK, @luqmana sorry for the confusion, some of my comments were a bit outdated by commit 2eeb83d. However, I've updated them as appropriate. In general, this looks pretty good. I made a few comments inline about things that should be updated. but the biggest thing is that I think we need more and better tests. First, we should test the type system parts better:
r+ with tests added and comments addressed. |
@luqmana looking good! I thought of one last set of tests I think we should have, which is to check that attempts to declare rust fns that use
and especially:
|
Fixes #2057. Example: ```Rust #[no_std]; type c_char = u8; type c_int = i32; type size_t = uint; extern { fn printf(format: *c_char, ...) -> c_int; } #[lang="fail_bounds_check"] fn fail_bounds_check(_: *c_char, _: size_t, _: size_t, _: size_t) {} #[start] #[fixed_stack_segment] fn main(_: int, _: **u8) -> int { unsafe { let msg = bytes!("Hello World!
This is essential for Objective-C bindings. Awesome! |
…lexendoo Add `multiple_unsafe_ops_per_block` lint Adds a lint, which restricts an `unsafe` block to only one unsafe operation. Closes rust-lang#10064 --- changelog: New lint: [`multiple_unsafe_ops_per_block`] [rust-lang#10206](rust-lang/rust-clippy#10206) <!-- changelog_checked -->
Fixes #2057.
Example:
Output: