Rust types in FFI lint

[alexcrichton]

Right now we have a lint mode which warns about the usage of rust types in extern blocks. This makes sure that by default you don't pass rust types into C functions. What we don't have is a lint going the other way which makes sure that C can't get Rust types from Rust. I believe that we need to expand the FFI lint to crawl extern functions as well as extern blocks.

The exact types which should be allowed is a little questionable. Some things that would be nice to have a defined ABI/FFI for would, but may currently not be working:

• Option<&T> and Option<~T>. See Nullable-pointer Options aren't FFI-compatible with the base pointer types. #11303, but this is currently broken. Do we want to commit to this ABI and say that it's valid to use to interface with C?
• ~T and &T, are these valid FFI types? The rust type system guarantees they are never null, but there's no guarantee that C handed you something that's not null.
• &str - should this be valid to pass in/out? This would require something along the lines of rust.h

To be conservative, we could only allow primitives (minus int and uint) plus *T, but this is quite limiting and makes FFI a little more difficult.

Nominating.

[pnkfelix]

We do not need this for 1.0. But it will be useful. Assigning P-high for now.

[japaric]

@alexcrichton We now have the improper_ctypes lint, can this be closed?

[alexcrichton]

In theory improper_ctypes is the lint that this would go under, but it doesn't handle cases like &str just yet (as far as I know), so this can be used to track expanding the improper_ctypes lint to more use cases.

[mzabaluev]

To pass &str in and out of C you either need to use some adapter functionality like rust-lang/rfcs#494, or define the underlying structure in a C header and use that on the C side in the function/callback signatures.

[TimNN]

I think most of this has been addressed by #26583:

• Option<&T> is allowed (if T is a proper ctype)
• &T is allowed (if T is a proper ctype)
• slices and str are not allowed

There is already a separate issue for checking extern fn's: #19834

So I think this issue can be closed, if any of the three points above should be changed I would propose opening separate issues for them.

[alexcrichton]

Sounds good to me!