-
Notifications
You must be signed in to change notification settings - Fork 129
Update the rust toolchain to nightly-2022-05-03
#1181
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
Conversation
tedinski
left a comment
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.
Other than the subtleties of the discriminant change it looks good, should get a second approval from someone on that.
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.
Is there Rust documentation to point to here?
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.
Nope... I can point to the code where I derived this comment from though.
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.
Make this a helper function on the type?
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.
Also, this will turn ssize_t into uint64_t instead of size_t. It would be nice to handle the CInt types specially here
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.
ok... let me create a helper function in the bindings crate to deal with different types.
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.
Why do we need to ignore generators?
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.
Because we don't codegen them and they end up with size 0 despite what their layout says.
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.
BTW, I changed the check to see if the size of the destination is 0, which today will exclude generators. The first check might be redundant now, but I guess it doesn't hurt for now.
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.
No location available?
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 can probably fix that. Let me see. I just took this code from the way we handle assignment.
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.
That's cleaner :)
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.
Does the comment below need to be updated?
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.
Yep
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.
Clever
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.
Why is there a cast 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.
this might be leftover from previous attempts... :)
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.
This comment doesn't seem accurate (don't see a tuple, and nonnull should perhaps be nonzero).
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.
yes, it is outdated
|
@zhassan-aws @danielsn would you like to take a look at the new revision? Cheers! |
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.
Nice!
This compiles but regression is failing due to unimplemented statement.
Box<T> now users NonNull<T> instead of raw pointer.
We codegen an assignment to non-det value per documentation. See more information here: - rust-lang/rust#95125
After the merge, the previous wrapping sub logic was triggering a panic due to u128 -> i64 conversion. There were also other overflow issues when trying to convert the `niche_value` to unsigned. For now, I'm disabling the coversion check which I believe is too strict. We should consider implementing a more flexible check later that can be controlled by the user without affecting the internal compiler codegen.
- Improve comments. - Remove wrong cast to i64. - Fix statement location. - Create util function to create unsigned type.
5deac08 to
dbec9fc
Compare
| pub fn to_unsigned(&self) -> Option<Self> { | ||
| let concrete = self.unwrap_typedef(); | ||
| match concrete { | ||
| CInteger(CIntType::SSizeT) => Some(CInteger(CIntType::SizeT)), |
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.
Aren't there some other types that could go here too?
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 could include Bool which would be a no-op and I could handle CBitField but I noticed that we don't handle that in neither signed() or unsigned() so we should probably add some logic there too. For us to add support to Char we would need access to the machine model. Is there any other type you would like to see?
Let me know what you prefer and I can add that as a follow up PR.
danielsn
left a comment
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 had one comment but it is a minor one.
Description of changes:
Update the rust toolchain to
nightly-2022-05-03. There were many issues that had to be fixed to upgrade the toolchain. I split the changes into the following commits:core::ptr::Uniqueon top ofNonNullrust-lang/rust#96010).Resolved issues:
Resolves #1162
Call-outs:
This change disables conversion checks. I am open to discussion, but I think this check is too strict and it was rather complicating our codegen logic. I propose to instrument casting later based on user configuration.
Testing:
How is this change tested? Old tests
Is this a refactor change? No
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.