-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Replace most uses of pointer::offset
with add
and sub
#100822
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
Some changes occurred in compiler/rustc_codegen_gcc cc @antoyo Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 |
|
||
// Verify copy | ||
for byte in 0..size { | ||
unsafe { | ||
assert_eq!(*dst.as_ptr().offset(offset + byte as isize), src[byte as usize]); | ||
assert_eq!(*dst.as_ptr().add(offset + byte), src[byte as usize]); |
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.
sneaky: offset
was {integer}
previously inferred to isize
, now to usize
.
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.
Looks like byte
was previously i32
(because unconstrained, as it was always as
ed) and is now usize
? So it can probably be src[byte]
too.
(It would be nice to have a warning for T-to-T as
casts...)
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 was thinking about linting T2T casts too, while doing these refactorings. It should probably be easy to add 🤔
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.
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 guess the problem is if you want to keep it -- say it's there to be resilient to c_int
widths or something, where it's c_int as i64
, which might be a nop sometimes.
For a clippy lint saying "hey, just allow it" is fine, but for rustc lints we generally want to be able to give a "or write ______ instead to make it obvious why you want to keep it like this" suggestion.
Nothing jumped to mind to me for how to do that, but hopefully you'll come up with something clever to lint only in the valuable places.
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.
Not linting i64 as c_int
is probably possible by recording in hir (?) that c_int
is a type alias, but not linting c_int as i64
I think it impossible, there is simply no way to differentiate a variable of type c_int
with a variable of type i64
I believe (if c_int
is an alias to i64
)
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.
As a second thought, would this still be useful as a allow-by-default lint? 🤔
ptr::swap(l.offset(*end_l as isize), r.offset(-1)); | ||
r = r.offset(-1); | ||
end_l = end_l.sub(1); | ||
ptr::swap(l.add(*end_l as usize), r.sub(1)); |
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.
Not this PR, but consider following along to use usize::from(*end_l)
here -- I went off to check that *end_l
wasn't signed, and if it was a from
then it'd be obvious that it's unsigned (since the from
wouldn't compile for signed -> unsigned).
@@ -75,7 +75,7 @@ pub unsafe fn find_eh_action(lsda: *const u8, context: &EHContext<'_>) -> Result | |||
|
|||
let call_site_encoding = reader.read::<u8>(); | |||
let call_site_table_length = reader.read_uleb128(); | |||
let action_table = reader.ptr.offset(call_site_table_length as isize); | |||
let action_table = reader.ptr.add(call_site_table_length as usize); |
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.
Not this PR's problem, but it's interesting that this reads a u64
and then offset
s it without any checking.
@bors r+ rollup |
As PR title says, it replaces
pointer::offset
in compiler and standard library withpointer::add
andpointer::sub
. This generally makes code cleaner, easier to grasp and removes (or, well, hides) integer casts.This is generally trivially correct,
.offset(-constant)
is just.sub(constant)
,.offset(usized as isize)
is just.add(usized)
, etc. However in some cases we need to be careful with signs of things.r? @scottmcm
split off from #100746