Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upRewrite the improper_ctypes lint. #26583
Conversation
rust-highfive
assigned
pcwalton
Jun 26, 2015
This comment has been minimized.
This comment has been minimized.
|
r? @pcwalton (rust_highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
|
With some help on IRC, I got part of the way handling projection types (54e183f). Still doesn't work completely correctly, though; not sure what's missing. |
This comment has been minimized.
This comment has been minimized.
|
|
eefriedman
force-pushed the
eefriedman:lint-ffi
branch
2 times, most recently
from
060b6eb
to
f951898
Jun 27, 2015
This comment has been minimized.
This comment has been minimized.
|
Rebased, and updated with some handling for late-bound lifetimes. Ready to be reviewed, I think? |
This comment has been minimized.
This comment has been minimized.
|
|
eefriedman
force-pushed the
eefriedman:lint-ffi
branch
from
f951898
to
09cfcba
Jul 4, 2015
This comment has been minimized.
This comment has been minimized.
|
Rebased. |
This comment has been minimized.
This comment has been minimized.
|
Ping. |
This comment has been minimized.
This comment has been minimized.
|
r? @nrc |
rust-highfive
assigned
nrc
and unassigned
pcwalton
Jul 21, 2015
nrc
reviewed
Jul 21, 2015
| pub fn is_ffi_safe(&'tcx self, cx: &ctxt<'tcx>) -> bool { | ||
| !self.type_contents(cx).intersects(TC::ReachesFfiUnsafe) | ||
| } | ||
|
|
This comment has been minimized.
This comment has been minimized.
nrc
Jul 21, 2015
Member
Does this mean we no longer use ReachesFfiUnsafe at all? If so, it should be removed, not just this helper function.
nrc
reviewed
Jul 21, 2015
| /// "nullable pointer optimization". Currently restricted | ||
| /// to function pointers and references, but could be | ||
| /// expanded to cover NonZero raw pointers and newtypes. | ||
| fn is_repr_nullable_ptr<'tcx>(variants: &Vec<Rc<ty::VariantInfo<'tcx>>>) -> bool { |
This comment has been minimized.
This comment has been minimized.
nrc
Jul 21, 2015
Member
Can we share this code with trans? I'm pretty uncomfortable with having two different ways of answering this question.
This comment has been minimized.
This comment has been minimized.
eefriedman
Jul 21, 2015
Author
Contributor
Pulling the whole algorithm out of trans into librustc is rather complicated... I can do it, but I think I'll submit it as a separate PR (it's a few hundred lines of code).
nrc
reviewed
Jul 21, 2015
| } | ||
| ty::TyTuple(ref tys) => { | ||
| // The layout of tuples is implicitly repr(C). | ||
| // FIXME: Is that correct? |
This comment has been minimized.
This comment has been minimized.
nrc
Jul 21, 2015
Member
It is currently correct and unlikely to change (although technically, no guarantees).
This comment has been minimized.
This comment has been minimized.
nrc
Jul 21, 2015
Member
After some discussion on IRC - why are tuples ever OK by the FFI lint? Since C has no tuples, it seems we should lint against passing them to C.
This comment has been minimized.
This comment has been minimized.
eefriedman
Jul 21, 2015
Author
Contributor
This follows what the old FFI lint did; I guess I can try changing it.
nrc
reviewed
Jul 21, 2015
| self.check_type_for_ffi(cache, m.ty) | ||
| } | ||
|
|
||
| // FIXME: Maybe we want to prohibit arrays of zero-size types? |
This comment has been minimized.
This comment has been minimized.
nrc
Jul 21, 2015
Member
You should probably check for ZSTs at the 'top level' of this function - I believe it would be an error to pass a struct with a aero-sized field across FFI too?
nrc
reviewed
Jul 21, 2015
|
|
||
| ty::TyBareFn(..) => { | ||
| // FIXME: Implement | ||
| FfiSafe |
This comment has been minimized.
This comment has been minimized.
nrc
Jul 21, 2015
Member
Better to be unsafe until this is implemented. Or perhaps add FfiUnimplemented
nrc
reviewed
Jul 21, 2015
| } | ||
|
|
||
| // Primitive types with a stable representation. | ||
| ty::TyBool | ty::TyInt(..) | ty::TyUint(..) | |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
eefriedman
Jul 21, 2015
Author
Contributor
They are; I'll rearrange the function to make that more obvious.
This comment has been minimized.
This comment has been minimized.
tomjakubowski
Jul 22, 2015
Contributor
Why are they considered unsafe for FFI? Are they not guaranteed to be defined the same as (one of) size_t/ssize_t, uintptr_t/intptr_t, on all our supported platforms?
On Jul 21, 2015, at 14:38, Nick Cameron notifications@github.com wrote:
In src/librustc_lint/builtin.rs:
ty::TyRawPtr(ref m) | ty::TyRef(_, ref m) => {self.check_type_for_ffi(cache, m.ty)}
// FIXME: Maybe we want to prohibit arrays of zero-size types?ty::TyArray(ty, _) => {self.check_type_for_ffi(cache, ty)}
ty::TyBareFn(..) => {// FIXME: ImplementFfiSafe}
// Primitive types with a stable representation. Shouldn't usize and isize be FfiUnsafe?ty::TyBool | ty::TyInt(..) | ty::TyUint(..) |—
Reply to this email directly or view it on GitHub.
This comment has been minimized.
This comment has been minimized.
tomjakubowski
Jul 22, 2015
Contributor
If you were writing a malloc replacement in Rust, for example, you'd likely use size/usize internally, and it seems likely that you'd want to use those as well in your extern signature for tjmalloc or whatever.
The alternative is to use libc's size_t type alias in those signatures, but that seems to just be shoving the problem elsewhere.
On Jul 21, 2015, at 14:38, Nick Cameron notifications@github.com wrote:
In src/librustc_lint/builtin.rs:
ty::TyRawPtr(ref m) | ty::TyRef(_, ref m) => {self.check_type_for_ffi(cache, m.ty)}
// FIXME: Maybe we want to prohibit arrays of zero-size types?ty::TyArray(ty, _) => {self.check_type_for_ffi(cache, ty)}
ty::TyBareFn(..) => {// FIXME: ImplementFfiSafe}
// Primitive types with a stable representation. Shouldn't usize and isize be FfiUnsafe?ty::TyBool | ty::TyInt(..) | ty::TyUint(..) |—
Reply to this email directly or view it on GitHub.
This comment has been minimized.
This comment has been minimized.
eefriedman
Jul 22, 2015
Author
Contributor
They aren't really unsafe, per se. We just want to discourage people from using them; it's usually a good idea to use types from the libc crate in FFI signatures.
Granted, it used to be more of a concern when isize was named int.
This comment has been minimized.
This comment has been minimized.
tomjakubowski
Jul 22, 2015
Contributor
The alternative is to use libc's size_t type alias in those signatures, but that seems to just be shoving the problem elsewhere.
By that I meant, by disallowing usize or size in FFI signatures: there are now two potential problems, that usize/size don't correspond to size_t/ssize_t, and that the libc::size_t and libc::ssize_t aliases are wrong. You'd need a cast somewhere, probably inside the FFI function, from libc::size_t (which is something like u64) to usize, which could cause hidden errors in the case that the alias in libc is wrong.
This comment has been minimized.
This comment has been minimized.
eefriedman
Jul 22, 2015
Author
Contributor
You might be right. That said, the old improper_ctypes lint did exactly the same thing, so I don't really want to change it here. Please file a bug, or open a thread on https://internals.rust-lang.org.
eefriedman
force-pushed the
eefriedman:lint-ffi
branch
3 times, most recently
from
dcc0cbb
to
484d071
Jul 22, 2015
This comment has been minimized.
This comment has been minimized.
|
Updated to address review comments. Function pointers are now checked. Tuples are now disallowed. Zero-size structs are now disallowed. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Seems reasonable |
This comment has been minimized.
This comment has been minimized.
|
@bors r+ |
This comment has been minimized.
This comment has been minimized.
|
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
|
bors
added a commit
that referenced
this pull request
Jul 23, 2015
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
|
eefriedman
force-pushed the
eefriedman:lint-ffi
branch
from
8d47c3d
to
858a1b9
Jul 23, 2015
This comment has been minimized.
This comment has been minimized.
|
Fixed again... |
This comment has been minimized.
This comment has been minimized.
|
@bors r+ |
This comment has been minimized.
This comment has been minimized.
|
|
This comment has been minimized.
This comment has been minimized.
|
|
bors
added a commit
that referenced
this pull request
Jul 23, 2015
This comment has been minimized.
This comment has been minimized.
|
|
eefriedman
force-pushed the
eefriedman:lint-ffi
branch
from
858a1b9
to
6fa17b4
Jul 24, 2015
This comment has been minimized.
This comment has been minimized.
|
Fixed again... |
eefriedman commentedJun 26, 2015
Makes the lint a bit more accurate, and improves the quality of the diagnostic
messages by explicitly returning an error message.