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

Rewrite the improper_ctypes lint. #26583

Merged
merged 1 commit into from Jul 24, 2015

Conversation

Projects
None yet
9 participants
@eefriedman
Copy link
Contributor

eefriedman commented Jun 26, 2015

Makes the lint a bit more accurate, and improves the quality of the diagnostic
messages by explicitly returning an error message.

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Jun 26, 2015

r? @pcwalton

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

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jun 26, 2015

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.

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jun 27, 2015

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

@eefriedman eefriedman force-pushed the eefriedman:lint-ffi branch 2 times, most recently from 060b6eb to f951898 Jun 27, 2015

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jul 2, 2015

Rebased, and updated with some handling for late-bound lifetimes. Ready to be reviewed, I think?

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 4, 2015

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

@eefriedman eefriedman force-pushed the eefriedman:lint-ffi branch from f951898 to 09cfcba Jul 4, 2015

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jul 4, 2015

Rebased.

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jul 21, 2015

Ping.

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Jul 21, 2015

r? @nrc

@rust-highfive rust-highfive assigned nrc and unassigned pcwalton 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.

@nrc

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.

/// "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.

@nrc

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.

@eefriedman

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).

}
ty::TyTuple(ref tys) => {
// The layout of tuples is implicitly repr(C).
// FIXME: Is that correct?

This comment has been minimized.

@nrc

nrc Jul 21, 2015

Member

It is currently correct and unlikely to change (although technically, no guarantees).

This comment has been minimized.

@nrc

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.

@eefriedman

eefriedman Jul 21, 2015

Author Contributor

This follows what the old FFI lint did; I guess I can try changing it.

self.check_type_for_ffi(cache, m.ty)
}

// FIXME: Maybe we want to prohibit arrays of zero-size types?

This comment has been minimized.

@nrc

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?


ty::TyBareFn(..) => {
// FIXME: Implement
FfiSafe

This comment has been minimized.

@nrc

nrc Jul 21, 2015

Member

Better to be unsafe until this is implemented. Or perhaps add FfiUnimplemented

}

// Primitive types with a stable representation.
ty::TyBool | ty::TyInt(..) | ty::TyUint(..) |

This comment has been minimized.

@nrc

nrc Jul 21, 2015

Member

Shouldn't usize and isize be FfiUnsafe?

This comment has been minimized.

@eefriedman

eefriedman Jul 21, 2015

Author Contributor

They are; I'll rearrange the function to make that more obvious.

This comment has been minimized.

@tomjakubowski

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: Implement
    
  •            FfiSafe
    
  •        }
    
  •        // Primitive types with a stable representation.
    
  •        ty::TyBool | ty::TyInt(..) | ty::TyUint(..) |
    
    Shouldn't usize and isize be FfiUnsafe?


Reply to this email directly or view it on GitHub.

This comment has been minimized.

@tomjakubowski

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: Implement
    
  •            FfiSafe
    
  •        }
    
  •        // Primitive types with a stable representation.
    
  •        ty::TyBool | ty::TyInt(..) | ty::TyUint(..) |
    
    Shouldn't usize and isize be FfiUnsafe?


Reply to this email directly or view it on GitHub.

This comment has been minimized.

@eefriedman

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.

@tomjakubowski

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.

@eefriedman

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 eefriedman force-pushed the eefriedman:lint-ffi branch 3 times, most recently from dcc0cbb to 484d071 Jul 22, 2015

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jul 22, 2015

Updated to address review comments.

Function pointers are now checked. Tuples are now disallowed. Zero-size structs are now disallowed. is_repr_nullable_ptr is still a separate function; unifying it with the trans enum handling is going to be a big task.

@tomjakubowski

This comment has been minimized.

Copy link
Contributor

tomjakubowski commented Jul 22, 2015

Any chance fixes (or tests, if these commits already fix them) for #20098 and #19834 could slip in? :-)

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jul 22, 2015

This already fixes and tests #20098 (Box was affected by the same issue as String). #19834 is essentially orthogonal; I don't want to make too many changes at once.

@nrc

This comment has been minimized.

Copy link
Member

nrc commented Jul 22, 2015

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).

Seems reasonable

@nrc

This comment has been minimized.

Copy link
Member

nrc commented Jul 22, 2015

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 22, 2015

📌 Commit 484d071 has been approved by nrc

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 22, 2015

⌛️ Testing commit 484d071 with merge d7e2f6f...

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 23, 2015

📌 Commit 8d47c3d has been approved by alexcrichton

bors added a commit that referenced this pull request Jul 23, 2015

Auto merge of #26583 - eefriedman:lint-ffi, r=alexcrichton
Makes the lint a bit more accurate, and improves the quality of the diagnostic
messages by explicitly returning an error message.
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 23, 2015

⌛️ Testing commit 8d47c3d with merge 3825fc1...

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 23, 2015

💔 Test failed - auto-mac-64-nopt-t

@eefriedman eefriedman force-pushed the eefriedman:lint-ffi branch from 8d47c3d to 858a1b9 Jul 23, 2015

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jul 23, 2015

Fixed again...

@nrc

This comment has been minimized.

Copy link
Member

nrc commented Jul 23, 2015

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 23, 2015

📌 Commit 858a1b9 has been approved by nrc

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 23, 2015

⌛️ Testing commit 858a1b9 with merge 48ef346...

bors added a commit that referenced this pull request Jul 23, 2015

Auto merge of #26583 - eefriedman:lint-ffi, r=nrc
Makes the lint a bit more accurate, and improves the quality of the diagnostic
messages by explicitly returning an error message.
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 23, 2015

💔 Test failed - auto-win-msvc-64-opt

Rewrite the improper_ctypes lint.
Makes the lint a bit more accurate, and improves the quality of the diagnostic
messages by explicitly returning an error message.

The new lint is also a little more aggressive: specifically, it now
rejects tuples, and it recurses into function pointers.

@eefriedman eefriedman force-pushed the eefriedman:lint-ffi branch from 858a1b9 to 6fa17b4 Jul 24, 2015

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jul 24, 2015

Fixed again...

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Jul 24, 2015

@bors: r=nrc 6fa17b4

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 24, 2015

⌛️ Testing commit 6fa17b4 with merge 68e0d13...

bors added a commit that referenced this pull request Jul 24, 2015

Auto merge of #26583 - eefriedman:lint-ffi, r=nrc
Makes the lint a bit more accurate, and improves the quality of the diagnostic
messages by explicitly returning an error message.

@bors bors merged commit 6fa17b4 into rust-lang:master Jul 24, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@tamird tamird referenced this pull request Jul 26, 2015

Merged

Fix compile on nightly #1836

@arielb1 arielb1 referenced this pull request Sep 15, 2015

Merged

1.3 relnotes #28408

SSheldon added a commit to SSheldon/rust-objc that referenced this pull request Sep 20, 2015

Fix zero-size struct improper_ctypes warnings.
These warnings starting appearing from rust-lang/rust#26583.

SSheldon added a commit to SSheldon/rust-dispatch that referenced this pull request Sep 21, 2015

SSheldon added a commit to SSheldon/rust-block that referenced this pull request Oct 10, 2015

@TimNN TimNN referenced this pull request Dec 20, 2015

Closed

Rust types in FFI lint #12608

rkruppe added a commit to rkruppe/rust that referenced this pull request Feb 14, 2018

[improper_ctypes] Stop complaining about repr(usize) and repr(isize) …
…enums

This dates back to at least rust-lang#26583. At the time, usize and isize were considered ffi-unsafe to nudge people away from them, but this changed in the aforementioned PR, making it inconsistent to complain about it in enum discriminants. In fact, repr(usize) is probably the best way to interface with `enum Foo : size_t { ... }`.

rkruppe added a commit to rkruppe/rust that referenced this pull request Feb 15, 2018

[improper_ctypes] Stop complaining about repr(usize) and repr(isize) …
…enums

This dates back to at least rust-lang#26583. At the time, usize and isize were considered ffi-unsafe to nudge people away from them, but this changed in the aforementioned PR, making it inconsistent to complain about it in enum discriminants. In fact, repr(usize) is probably the best way to interface with `enum Foo : size_t { ... }`.

rkruppe added a commit to rkruppe/rust that referenced this pull request Feb 15, 2018

[improper_ctypes] Stop complaining about repr(usize) and repr(isize) …
…enums

This dates back to at least rust-lang#26583. At the time, usize and isize were considered ffi-unsafe to nudge people away from them, but this changed in the aforementioned PR, making it inconsistent to complain about it in enum discriminants. In fact, repr(usize) is probably the best way to interface with `enum Foo : size_t { ... }`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.