[MOD-10008] Reduce the amount of unsafe code by using more idiomatic Rust definitions#6257
[MOD-10008] Reduce the amount of unsafe code by using more idiomatic Rust definitions#6257LukeMathWalker merged 8 commits intomasterfrom
Conversation
ebebf31 to
9f863c4
Compare
9f863c4 to
46cab95
Compare
46cab95 to
e7033d4
Compare
zeenix
left a comment
There was a problem hiding this comment.
it would have been better to do the splitting & merging of files in separate commit(s) so it's easier to see the main change for reviewers.
LGTM otherwise.
| } | ||
|
|
||
| // Check, at compile-time, that `BufferReader` and `ffi::BufferReader` have the same representation. | ||
| const _: () = { |
There was a problem hiding this comment.
why not an ignored test instead?
There was a problem hiding this comment.
I didn't think I could have a const fn as a test, but today I learned it's possible.
Done in afe41ac
There was a problem hiding this comment.
That's not what I meant. :) I didn't know that either.
I was talking about:
#[test]
#[ignore]which tests the code to compile but not actually run.
There was a problem hiding this comment.
While that would be technically correct (i.e. the current test desugars to a no-op at runtime), I think it'd be confusing to see that #[ignore] for folks who are not too well-versed into the semantics of const evaluation.
Since the penalty is negligible, I prefer to leave it as is.
There was a problem hiding this comment.
I'm just wondering if declaring the test fn as const is doing what you are thinking. Did you find any docs on this. I couldn't. I'd be fine with just turning it back to const _: () = that you originally did.
There was a problem hiding this comment.
It seems to, but then it only checks it if tests are built. So yeah, probably better to revert back. Done in 5e61a40
chesedo
left a comment
There was a problem hiding this comment.
nit: small comment improvement
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6257 +/- ##
==========================================
- Coverage 88.87% 88.79% -0.08%
==========================================
Files 239 241 +2
Lines 40258 40623 +365
Branches 3165 3265 +100
==========================================
+ Hits 35780 36073 +293
- Misses 4443 4513 +70
- Partials 35 37 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| const POSITION_OFFSET_MATCHES: bool = | ||
| offset_of!(BufferReader<'static>, position) == offset_of!(ffi::BufferReader, pos); | ||
|
|
||
| // Conditional compilation failure on mismatch |
There was a problem hiding this comment.
What should be done if the panic occurs?
What steps should we do?
Revert this PR?
Maybe add a comment with some directions.
Co-authored-by: Pieter <[email protected]>
Co-authored-by: Pieter <[email protected]>
1eab83f to
c9d1afa
Compare
|
I've rebased on the latest |
Describe the changes in the pull request
Correctness is our paramount concern when manipulating C types in Rust.
When defining idiomatic Rust wrappers, we are caught between a rock and a hard place:
fficrate) we get layout correctness for free. If the C code changes, the bindings will change and any discrepancy will cause a compilation error in Rust. At the same time, we're working with raw pointers everywhere, thus forcing us to use a lot ofunsafecode where mistakes can be made more easily.unsafecode but we risk layout drift.This PR tries to strike a balance for the
buffer.*module.We stick to wrapping the
ffitype forBuffer, but we use more idiomatic Rust types for reader and writer. We add compile-time assertions to guard against layout drift.Mark if applicable